linux-kernel - Re: [PATCH v5 01/14] slab: add opt-in caching layer of percpu sheaves

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: <b923fd8a-4f07-4689-a0cf-4ac5b85c6fe5@suse.cz>
Date: Sat, 13 Sep 2025 22:32:54 +0200
From: Vlastimil Babka <vbabka@...e.cz>
To: Mateusz Guzik <mjguzik@...il.com>
Cc: Suren Baghdasaryan <surenb@...gle.com>,
 "Liam R. Howlett" <Liam.Howlett@...cle.com>,
 Christoph Lameter <cl@...two.org>, David Rientjes <rientjes@...gle.com>,
 Roman Gushchin <roman.gushchin@...ux.dev>, Harry Yoo <harry.yoo@...cle.com>,
 Uladzislau Rezki <urezki@...il.com>, linux-mm@...ck.org,
 linux-kernel@...r.kernel.org, rcu@...r.kernel.org,
 maple-tree@...ts.infradead.org
Subject: Re: [PATCH v5 01/14] slab: add opt-in caching layer of percpu sheaves

On 9/13/25 16:35, Mateusz Guzik wrote:
> On Wed, Jul 23, 2025 at 03:34:34PM +0200, Vlastimil Babka wrote:
>> The sheaves do not distinguish NUMA locality of the cached objects.
> 
> While currently sheaves are opt-in, to my understanding the plan is to
> make this the default.
> 
> I would argue a hard requirement for a general purpose allocator in this
> day and age is to provide node-local memory by default. Notably if you
> have a workload which was careful to bind itself to one node, it should
> not receive memory backed by other nodes unless there is no other
> option. AFAIU this is satisifed with the stock allocator on the grounds
> of running on a given domain, without having to explicitly demand memory
> from it for everyting.
> 
> I expect the lack of NUMA-awareness to result in increased accumulation
> of "mismatched" memory as uptime goes up, violating the above.

Yeah this is addressed in later patch in the series "mm, slub: skip percpu
sheaves for remote object freeing" and then "mm, slab: allow NUMA restricted
allocations to use percpu sheaves" further improves it. I should update
commit log in this patch too.

> I admit though I don't have a good solution as to how to handle the
> "bad" frees. Someone (I think you?) stated that one of the previous
> allocators was just freeing to per-domain lists or arrays and that was
> causing trouble -- perhaps this would work if it came with small limits
> in place for how big these can get?

Yes, the alien arrays of SLAB, with their dreaded periodical flushing.
To avoid that the later patch simply skips the percpu sheaf. Only about 5%
of frees seem to be remote, so 95% will still benefit.