Message-ID: <8b27bcf4-a404-4585-aeff-8627b5a857d1@quicinc.com>
Date: Wed, 23 Jul 2025 18:21:57 +0800
From: Zhenhua Huang <quic_zhenhuah@...cinc.com>
To: Harry Yoo <harry.yoo@...cle.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

Thanks Harry for your quick comments.

On 2025/7/23 17:19, 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".

Oh, Yeah, it's an alloc_tag change. Thanks and will update.

> 
> 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?

Yes. The idea is similar with: when we are willing to see slab 
allocation stacks we add "slab_debug=U". Basically if we enable page 
owner only, we can't see slab allocation stacks as well.

> 
> 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.

Actually, we can still track the total slab usage through 
alloc_slab_page; in my opinion, what's being disabled here is the 
accounting at the slab object level.

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

This, as I understand it, is the core concern addressed by the patch. 
The background is that some OEMs have raised concerns about the memory 
overhead introduced by this debug feature when used in production 
builds. While page-level tracking can now be compressed into page flags, 
I haven't seen a similar solution for slab object-level tracking yet.
In a real Android platform, we see 24MB memory are cost from 
alloc_slab_obj_exts :)

> 
>> 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"?

Thanks for pointing out, will update.

> 
>> 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.

I should update my wording:) What I meant is that this case is similar 
to how we handle page owner versus slab_debug: typically, we enable page 
owner firstly, and only turn on slab_debug when we need detailed slab 
object tracking. Both are optional and left to the end user to decide 
whether to enable them.

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

Powered by blists - more mailing lists