linux-kernel - Re: [PATCH v4 06/22] slab: add sheaves to most caches

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] [day] [month] [year] [list]

Message-ID: <aXxaryFUrIFo7/hL@intel.com>
Date: Fri, 30 Jan 2026 15:15:59 +0800
From: Zhao Liu <zhao1.liu@...el.com>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: Harry Yoo <harry.yoo@...cle.com>, Petr Tesarik <ptesarik@...e.com>,
	Christoph Lameter <cl@...two.org>,
	David Rientjes <rientjes@...gle.com>,
	Roman Gushchin <roman.gushchin@...ux.dev>,
	Hao Li <hao.li@...ux.dev>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Uladzislau Rezki <urezki@...il.com>,
	"Liam R. Howlett" <Liam.Howlett@...cle.com>,
	Suren Baghdasaryan <surenb@...gle.com>,
	Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
	Alexei Starovoitov <ast@...nel.org>, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, linux-rt-devel@...ts.linux.dev,
	bpf@...r.kernel.org, kasan-dev@...glegroups.com
Subject: Re: [PATCH v4 06/22] slab: add sheaves to most caches

Hi Vlastimil,

> > vm_area_cachep's capacity seems to be adjusted to 60 and
> > maple_node_cache keeps 32 as the args setting.
> 
> Good to know. It is a bit larger.
> Hm I could have probably applied the args capacity before doing the roundup
> to make sheaf fill whole kmalloc size. Would add a few object for maple node
> I guess.

Re-considerring this formula:

the nr_objects in set_cpu_partial() in fact represents the half-full
case since it was used to calculate nr_slabs in slub_set_cpu_partial().

Therefore, the maximum capacity of this partial approach should be
nr_objects * 2 (and should actually be even larger, since it doesn't
account for the object on CPU's freelist).

But here, for sheaf, the implicit assumption is that it is completely
full, so that for the maximum capacity of objects per CPU, the sheaf
approach is "half" that of the partial approach.

Is this expected? I'm considering whether we should remove the
“divide by two” and instead calculate the sheaf capacity based on
half-full assumption (e.h., full main & empty spare).

Thanks,
Zhao