From: wangyushan <wangyushan12@huawei.com>
To: Jonathan Cameron <jonathan.cameron@huawei.com>,
Linus Walleij <linusw@kernel.org>
Cc: <alexandre.belloni@bootlin.com>, <arnd@arndb.de>,
<fustini@kernel.org>, <krzk@kernel.org>,
<linus.walleij@linaro.org>, <will@kernel.org>,
<linux-arm-kernel@lists.infradead.org>,
<linux-kernel@vger.kernel.org>, <fanghao11@huawei.com>,
<linuxarm@huawei.com>, <liuyonglong@huawei.com>,
<prime.zeng@hisilicon.com>, <wangzhou1@hisilicon.com>,
<xuwei5@hisilicon.com>, <linux-mm@vger.kernel.org>,
SeongJae Park <sj@kernel.org>,
Yushan Wang <wangyushan12@huawei.com>
Subject: Re: [PATCH 1/3] soc cache: L3 cache driver for HiSilicon SoC
Date: Fri, 6 Feb 2026 18:07:51 +0800 [thread overview]
Message-ID: <4c5eaf8f-2433-4971-b5d0-4f35acb2820e@huawei.com> (raw)
In-Reply-To: <20260204134020.00002393@huawei.com>
On 2/4/2026 9:40 PM, Jonathan Cameron wrote:
> On Wed, 4 Feb 2026 01:10:01 +0100
> Linus Walleij <linusw@kernel.org> 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
next prev parent reply other threads:[~2026-02-06 10:07 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-03 16:18 [PATCH 0/3] soc: Enable cache lockdown for HiSilicon L3 cache Yushan Wang
2026-02-03 16:18 ` [PATCH 1/3] soc cache: L3 cache driver for HiSilicon SoC Yushan Wang
2026-02-03 17:19 ` Arnd Bergmann
2026-02-04 9:51 ` wangyushan
2026-02-05 9:37 ` Krzysztof Kozlowski
2026-02-05 11:19 ` wangyushan
2026-02-05 11:23 ` Krzysztof Kozlowski
2026-02-05 11:30 ` wangyushan
2026-02-04 0:10 ` Linus Walleij
2026-02-04 9:53 ` wangyushan
2026-02-04 10:06 ` Linus Walleij
2026-02-04 13:40 ` Jonathan Cameron
2026-02-04 13:44 ` Jonathan Cameron
2026-02-05 2:20 ` SeongJae Park
2026-02-05 9:12 ` Linus Walleij
2026-02-05 10:18 ` Jonathan Cameron
2026-02-05 13:47 ` Linus Walleij
2026-02-05 14:38 ` Arnd Bergmann
2026-02-06 8:05 ` Linus Walleij
2026-02-05 14:37 ` Ben Horgan
2026-02-06 9:54 ` wangyushan
2026-02-06 16:15 ` Ben Horgan
2026-02-06 10:07 ` wangyushan [this message]
2026-02-06 10:44 ` Arnd Bergmann
2026-02-06 12:44 ` Linus Walleij
2026-02-04 2:47 ` kernel test robot
2026-02-03 16:18 ` [PATCH 2/3] soc cache: L3 cache lockdown support " Yushan Wang
2026-02-03 16:18 ` [PATCH 3/3] Documentation: soc cache: Add documentation to HiSilicon SoC cache Yushan Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4c5eaf8f-2433-4971-b5d0-4f35acb2820e@huawei.com \
--to=wangyushan12@huawei.com \
--cc=alexandre.belloni@bootlin.com \
--cc=arnd@arndb.de \
--cc=fanghao11@huawei.com \
--cc=fustini@kernel.org \
--cc=jonathan.cameron@huawei.com \
--cc=krzk@kernel.org \
--cc=linus.walleij@linaro.org \
--cc=linusw@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=liuyonglong@huawei.com \
--cc=prime.zeng@hisilicon.com \
--cc=sj@kernel.org \
--cc=wangzhou1@hisilicon.com \
--cc=will@kernel.org \
--cc=xuwei5@hisilicon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®