Re: [PATCH RFC 2/8] mm, slab: introduce slab_debug=N

[Vlastimil Babka (SUSE)]

On 9/24/26 16:48, Harry Yoo wrote:
> On Wed, Sep 23, 2026 at 05:45:07PM +0200, Vlastimil Babka (SUSE) wrote:
>> Enabling slab_debug has the side-effect of disabling all percpu caching
>> of objects (now via sheaves), which can be sometimes useful for saving
>> memory for e.g. kdump kernels. To make this possible without the
>> overhead (CPU or memory) of actual debugging options such as poisoning,
>> introduce a No-op debug option that only forces the debugging slow paths
>> and zero sheaf capacity.
> 
> Just to clarify, the intended behavior of slab_debug=- still
> does not change, right? (the name "No-op" could be confusing here I
> guess)

Yeah it doesn't change.

Perhaps, later in the series I should consider what exactly slab_tiny=1
slab_debug=- shhould do. Hm.

> And My LLM flagged an issue here (that I reviewed)
> 
> Implementing it as debug flag has a few side effects:
> 
>   - pointer hashing will be disabled unless hash_pointers=always is
>     specified. [+Cc: Kees]

Hm that likely should not happen with =N, will adjust.

>   - Disable slab merging. Since this does not affect object metadata
>     layout, this could be excluded.

Right, also we want merging with slab_tiny=1.

Thanks!