linux-kernel - Re: [PATCH 1/3] soc cache: L3 cache driver for HiSilicon SoC

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <cf0cc98b-75e0-40d9-93d4-dc2218a22d4d@huawei.com>
Date: Wed, 4 Feb 2026 17:53:08 +0800
From: wangyushan <wangyushan12@...wei.com>
To: Linus Walleij <linusw@...nel.org>
CC: <alexandre.belloni@...tlin.com>, <arnd@...db.de>, <fustini@...nel.org>,
	<Jonathan.Cameron@...wei.com>, <krzk@...nel.org>, <linus.walleij@...aro.org>,
	<will@...nel.org>, <linux-arm-kernel@...ts.infradead.org>,
	<linux-kernel@...r.kernel.org>, <fanghao11@...wei.com>,
	<liuyonglong@...wei.com>, <prime.zeng@...ilicon.com>,
	<wangzhou1@...ilicon.com>, <xuwei5@...ilicon.com>,
	<linux-mm@...r.kernel.org>, SeongJae Park <sj@...nel.org>, Yushan Wang
	<wangyushan12@...wei.com>
Subject: Re: [PATCH 1/3] soc cache: L3 cache driver for HiSilicon SoC



On 2/4/2026 8:10 AM, Linus Walleij wrote:
> Hi Yushan,
>
> thanks for your patch!

Thanks for review!

> On Tue, Feb 3, 2026 at 5:18 PM Yushan Wang <wangyushan12@...wei.com> wrote:
>> The driver will create a file of `/dev/hisi_l3c` on init, mmap
>> operations to it will allocate a memory region that is guaranteed to be
>> placed in L3 cache.
>>
>> The driver also provides unmap() to deallocated the locked memory.
>>
>> The driver also provides an ioctl interface for user to get cache lock
>> information, such as lock restrictions and locked sizes.
>>
>> Signed-off-by: Yushan Wang <wangyushan12@...wei.com>
> The commit message does not say *why* you are doing this?
>> +config HISI_SOC_L3C
>> +       bool "HiSilicon L3 Cache device driver"
>> +       depends on ACPI
>> +       depends on ARM64 || COMPILE_TEST
>> +       help
>> +         This driver provides the functions to lock L3 cache entries from
>> +         being evicted for better performance.
> Here is the reason though.

Sorry, I will include this into the commit message.
> Things like this need to be CC to linux-mm@...r.kernel.org.
>
> I don't see why userspace would be so well informed as to make decisions
> about what should be locked in the L3 cache and not?

This question is actually: should it be kernel or user space
application to decide if a cache lock should be applied?

Maybe the ideal situation is that this capability should be reserved into kernel space as a vendor specific optimization option. With the lack of knowledge of memory interleave etc the best move of an application might be allocate cache lock as much as possible.
> I see the memory hierarchy as any other hardware: a resource that is
> allocated and arbitrated by the kernel.
>
> The MM subsytem knows which memory is most cache hot.
> Especially when you use DAMON DAMOS, which has the sole
> purpose of executing actions like that. Here is a good YouTube.
> https://www.youtube.com/watch?v=xKJO4kLTHOI
>
> Shouldn't the MM subsystem be in charge of determining, locking
> down and freeing up hot regions in L3 cache?
Thanks for the link, I will see if there's any chance this can
cooperate with DAMON.

Gaps still exists here because DAMON operate with pages, but cache
works with cachelines, though the cache lock here supports cache
lock size larger than a page.
> 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.
Currently the patchset simply trusts that user knows well what
he is doing, which might not be good enough.

I will try to see if this could work with DAMON or madvice()
maybe :)

> Yours,
> Linus Walleij

Thanks,
Yushan