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: <aICpMWKNvhveAzth@hyeyoo>
Date: Wed, 23 Jul 2025 18:19:45 +0900
From: Harry Yoo <harry.yoo@...cle.com>
To: Zhenhua Huang <quic_zhenhuah@...cinc.com>
Cc: kent.overstreet@...ux.dev, 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

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.

> While In some scenarios, we may choose not to delve into SLUB allocation
> details if initial triage indicates that SLUB memory usage is within
> acceptable limits. To support this, a control knob is introduced to enable
> or disable SLUB object tracking.

But what if slab memory usage is not within acceptable limit,
reboot without noslub and profile it again?

You should expect to sacrifice some performance and memory by enabling
memory allocation profiling. I'm not sure if it's worth optimizing it
at the cost of disabling slab accounting entirely.

Anyway, that's my opinion - the memory allocation profiling
maintainers might say something different.

> The "noslub" knob disables SLUB tracking, preventing further allocation of
> slabobj_ext structures.

nit: "noslub" is not a good name because slub is an implementation
of slab allocator. For the same reason "slub_debug" is deprecated and
"slab_debug" is recommended instead. Maybe "noslab"?

> Signed-off-by: Zhenhua Huang <quic_zhenhuah@...cinc.com>
> ---
>  Documentation/mm/allocation-profiling.rst |  7 +++++-
>  include/linux/alloc_tag.h                 |  8 +++++++
>  lib/alloc_tag.c                           | 26 +++++++++++++++++------
>  mm/slub.c                                 | 10 ++++-----
>  4 files changed, 38 insertions(+), 13 deletions(-)
> 
> diff --git a/Documentation/mm/allocation-profiling.rst b/Documentation/mm/allocation-profiling.rst
> index 316311240e6a..9ecae74e0365 100644
> --- a/Documentation/mm/allocation-profiling.rst
> +++ b/Documentation/mm/allocation-profiling.rst
> @@ -18,7 +18,7 @@ kconfig options:
>    missing annotation
>  
>  Boot parameter:
> -  sysctl.vm.mem_profiling={0|1|never}[,compressed]
> +  sysctl.vm.mem_profiling={0|1|never}[,compressed][,noslub]
>  
>    When set to "never", memory allocation profiling overhead is minimized and it
>    cannot be enabled at runtime (sysctl becomes read-only).
> @@ -30,6 +30,11 @@ Boot parameter:
>    If compression fails, a warning is issued and memory allocation profiling gets
>    disabled.
>  
> +  The optional noslub parameter disables tracking of individual SLUB objects. This
> +  approach, similar to how page owner tracking works, relies on slub_debug for SLUB
> +  object insights instead. While this reduces memory overhead, it also limits the
> +  ability to observe detailed SLUB allocation behavior.

I think you don't really want to use slab_debug to account slab memory
if you care about performance & memory overhead.

>  sysctl:
>    /proc/sys/vm/mem_profiling
>  

-- 
Cheers,
Harry / Hyeonggon