From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout05.his.huawei.com (canpmsgout05.his.huawei.com [113.46.200.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 084CE364E8E for ; Fri, 6 Feb 2026 10:07:55 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.220 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770372477; cv=none; b=euDTbtwOVSgT88VImnpNy3hCTP76HS2sG1cClUe/qX99W2VFkq9kFMNoPHydzSby3jaNZbpiPB+4wSNfgYaDxSqmIK4MBVOOjwZjT3b14iYQ4HZZGRfaCoVpXqj11THnUnrCrzkRVqEQLB7FSP6KvVObTAv/rjk4G7/wVQTVo1k= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770372477; c=relaxed/simple; bh=tt/apNU651co1/FFDBARgi66XwWLSw6qcjsHG+8hCXA=; h=Message-ID:Date:MIME-Version:From:Subject:To:CC:References: In-Reply-To:Content-Type; b=omFJ5jmx0iylQ+2DITcyVDJTvrv5+jhEp//40IneQgZ8MIkluXtlcnHh7eddGfP3WKIhDlEiAkbJcLt2PTd6YUYCuvgdXZID4NaJdUYXV+o9I1rMN4T5s9TDI7b7HKbi3Z+NL3U9vXfy7R1GE8WmdS7l6J8Buc9Lul89qkr+mks= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=g0ZfPotU; arc=none smtp.client-ip=113.46.200.220 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="g0ZfPotU" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=tt/apNU651co1/FFDBARgi66XwWLSw6qcjsHG+8hCXA=; b=g0ZfPotUFYgfyMGRd9ZvMJ94EPrmBnyyyzf/2tUq+FbPqv7NNoHQi7IOhmzQaAJo0R/N+FwW6 PWbgcaHY//nD/aE78g5c/SkVs01zEJOlFVtyO+sCwj9QO7pJ71I5+blX3l8IusLX0BicDatvRwI 5iDLV1Pwb+xL7YqIu33oE5Y= Received: from mail.maildlp.com (unknown [172.19.162.197]) by canpmsgout05.his.huawei.com (SkyGuard) with ESMTPS id 4f6qS41Rtyz12LCb; Fri, 6 Feb 2026 18:04:04 +0800 (CST) Received: from dggemv712-chm.china.huawei.com (unknown [10.1.198.32]) by mail.maildlp.com (Postfix) with ESMTPS id 36DF140363; Fri, 6 Feb 2026 18:07:53 +0800 (CST) Received: from kwepemn100008.china.huawei.com (7.202.194.111) by dggemv712-chm.china.huawei.com (10.1.198.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Fri, 6 Feb 2026 18:07:53 +0800 Received: from [10.67.120.139] (10.67.120.139) by kwepemn100008.china.huawei.com (7.202.194.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.36; Fri, 6 Feb 2026 18:07:52 +0800 Message-ID: <4c5eaf8f-2433-4971-b5d0-4f35acb2820e@huawei.com> Date: Fri, 6 Feb 2026 18:07:51 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: wangyushan Subject: Re: [PATCH 1/3] soc cache: L3 cache driver for HiSilicon SoC To: Jonathan Cameron , Linus Walleij CC: , , , , , , , , , , , , , , , SeongJae Park , Yushan Wang References: <20260203161843.649417-1-wangyushan12@huawei.com> <20260203161843.649417-2-wangyushan12@huawei.com> <20260204134020.00002393@huawei.com> Content-Language: en-US In-Reply-To: <20260204134020.00002393@huawei.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems500001.china.huawei.com (7.221.188.70) To kwepemn100008.china.huawei.com (7.202.194.111) On 2/4/2026 9:40 PM, Jonathan Cameron wrote: > On Wed, 4 Feb 2026 01:10:01 +0100 > Linus Walleij wrote: > >> Shouldn't the MM subsystem be in charge of determining, locking >> down and freeing up hot regions in L3 cache? >> >> This looks more like userspace is going to determine that but >> how exactly? By running DAMON? Then it's better to keep the >> whole mechanism in the kernel where it belongs and let the >> MM subsystem adapt locked L3 cache to the usage patterns. > I haven't yet come up with any plausible scheme by which the MM > subsystem could do this. > > I think what we need here Yushan, is more detail on end to end > use cases for this.  Some examples etc as clearer motivation. > Hi, Let me try to explain the use case here. The idea is similar to this article: https://www.cl.cam.ac.uk/~rnw24/papers/201708-sigcomm-diskcryptnet.pdf Suppose we have data on SSD that need to be transferred through network. We have technologies like DDIO and IO stash to make data flow through L3 cache instead of DDR to avoid the influence of DDR bandwidth. But if something is to be done to the data instead of merely copying, and cores needs to participate, we'd like to make data to climb a bit higher up through the memory hierarchy and stay there before data processing is done. That is, correct amount of data being fetched to L3 cache, and consumed just in time, then free L3 for next batch. It is more of a userspace defined pipeline that utilizes capability provided by kernel, where cache locks are allocated and freed quickly with batches. In above use case, C2C latency is chosen to avoid DDR latency, precisely which L3 cache to store the data is not required. (For this part maybe including steering tag as the hint to choose the correct L3 is a smarter way, like AMD SDCIAE). Memory management is, in many way, independent to architecture and vendors, we might not want to take hardware specific feature into account when kernel makes decisions of, say, swapping a page or not, but we can control the hardware resource to lean more on a process, like resctl. Thanks, Yushan