Re: [PATCH v3 05/10] mm, slab: rework KMALLOC_RECLAIM handling of SLUB_TINY

[Harry Yoo <harry@kernel.org>]

On Thu, Nov 05, 2026 at 09:43:54AM +0100, Vlastimil Babka (SUSE) wrote:
> One (relatively minor) aspect of CONFIG_SLUB_TINY is the assumption that
> letting reclaimable and non-reclaimable caches merge will save more
> memory, which is more important on small systems than the page allocator
> level fragmentation (where distinguishing reclaimable slabs should
> help).
> 
> For now that has been achieved by #ifdefs that result in making the
> SLAB_RECLAIM_ACCOUNT no-op and aliasing KMALLOC_RECLAIM to
> KMALLOC_NORMAL on the enum values level.
> 
> With the goal of converting CONFIG_SLUB_TINY to a boot-time decision,
> rework this so that SLAB_RECLAIM_ACCOUNT and KMALLOC_RECLAIM are
> distinctly defined always.

Nice!

> Now, creation of kmalloc-rcl caches is
> avoided by assigning a pointer to the normal kmalloc cache on the
> kmalloc_caches array level.
> 
> To prepare disconnecting of this boot-time decision (and the evaluation
> of the need for kmalloc_no_objext) from CONFIG_SLUB_TINY, introduce a
> slub_tiny_enabled variable that's initialized to the CONFIG_SLUB_TINY
> state.
> 
> There is one minor functional change for CONFIG_SLUB_TINY=y. Since
> SLAB_RECLAIM_ACCOUNT is not 0 anymore, caches that differ only in that
> flag will stop being mergeable. If that turns out to have a noticeable
> impact on memory footprint, we can adjust the merging decisions to
> ignore SLAB_RECLAIM_ACCOUNT when slub_tiny_enabled is true.
> 
> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---

Looks good to me,
Reviewed-by: Harry Yoo (Meta) <harry@kernel.org>

-- 
Cheers,
Harry / Hyeonggon