linux-kernel - Re: [PATCH 1/1] mm: slub: Introduce one knob to control the track of slub object

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: <aqscos5ivap537qljhqa2pntrxfimfkfuflji62rl2picpvaiv@sams7xovbtn6>
Date: Wed, 23 Jul 2025 07:38:45 -0400
From: Kent Overstreet <kent.overstreet@...ux.dev>
To: Harry Yoo <harry.yoo@...cle.com>
Cc: Zhenhua Huang <quic_zhenhuah@...cinc.com>, rientjes@...gle.com, 
	vbabka@...e.cz, cl@...two.org, roman.gushchin@...ux.dev, surenb@...gle.com, 
	pasha.tatashin@...een.com, akpm@...ux-foundation.org, corbet@....net, linux-mm@...ck.org, 
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, quic_tingweiz@...cinc.com
Subject: Re: [PATCH 1/1] mm: slub: Introduce one knob to control the track of
 slub object

On Wed, Jul 23, 2025 at 06:19:45PM +0900, Harry Yoo wrote:
> The subject is a bit misleading. I think it should be something like
> "alloc_tag: add an option to disable slab object accounting".
> 
> On Wed, Jul 23, 2025 at 04:03:28PM +0800, Zhenhua Huang wrote:
> > Mem profiling feature tracks both "alloc_slab_page"(page level) and slub
> > object level allocations. To track object level allocations,
> > slabobj_ext consumes 16 bytes per object for profiling slub object if
> > CONFIG_MEMCG is set.
> > Based on the data I've collected, this overhead accounts for approximately
> > 5.7% of slub memory usage — a considerable cost.
> > w/ noslub  slub_debug=-
> > Slab:              87520 kB
> > w/o noslub slub_debug=-
> > Slab:              92812 kB
> 
> Yes, the cost is not small and I hate that we have to pay 16 bytes of
> memory overhead for each slab object when both memcg and memory profiling
> are enabled.

I believe we did something about this for page_obj_ext; the exact
pointer compression scheme we went with escapes me at the moment.

We did it for page and not slab because page_obj_ext is a large fixed
size overhead and the page allocator is slower anyways, but it's
conceivable we could do the same for slub if the memory overhead vs. cpu
overhead tradeoff is worth it.

And - pointer compression is a valuable technique in general; coming up
with some fast general purpose code (perhaps involving virtual mappings,
we're not so limited on virtual address space as we used to be) might be
worth someone's time exploring.