Re: [PATCH RFC v2 3/8] mm, slab: rework KMALLOC_RECLAIM handling of SLUB_TINY

[Hao Li]

On Thu, Nov 05, 2026 at 03:19:01PM +0000, Harry Yoo wrote:
> On Wed, Oct 28, 2026 at 07:43:14PM +0800, Hao Li wrote:
> > On Sat, Oct 24, 2026 at 09:07:25PM +0200, 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. 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@xxxxxxxxxx>
> > > ---
> > >  include/linux/slab.h | 10 ----------
> > >  mm/slab.h            |  5 +++--
> > >  mm/slab_common.c     | 12 ++++++------
> > >  mm/slub.c            |  2 ++
> > 
> > [...]
> > 
> > > diff --git a/mm/slab_common.c b/mm/slab_common.c
> > > index 02dfe4351e8b..33e76a0c3084 100644
> > > --- a/mm/slab_common.c
> > > +++ b/mm/slab_common.c
> > > @@ -1009,7 +1009,7 @@ new_kmalloc_cache(int idx, enum kmalloc_cache_type type)
> > >  	 * KMALLOC_NO_OBJ_EXT cache.
> > >  	 */
> > >  	if (!mem_cgroup_kmem_disabled()) {
> > > -		if (type == KMALLOC_NORMAL && KMALLOC_RECLAIM != KMALLOC_NORMAL)
> > > +		if (type == KMALLOC_NORMAL && !slab_tiny_enabled)
> > 
> > (While reviewing Harry's patch [1], I happened to notice a small inconsistency
> > in the current code. Since these lines are being touched in this series, I
> > figured I'd bring it up here, even though I haven't properly started reviewing
> > this series yet :D)
> > 
> > IIUC, for both KMALLOC_NORMAL and KMALLOC_PARTITION_START + n, if gfp has
> > __GFP_ACCOUNT set (and without __GFP_DMA/__GFP_RECLAIMABLE), the allocation is
> > redirected to KMALLOC_CGROUP.
> 
> Right.
> 
> > This seems to mean that neither KMALLOC_NORMAL
> > nor KMALLOC_PARTITION_START + n actually needs an objcg slot in obj_exts.
> 
> Right.
> 
> > Right now, KMALLOC_NORMAL already doesn't carry SLAB_MAY_ACCOUNT, but
> > KMALLOC_PARTITION_START + n still does.
> 
> Ouch, good catch!
> 
> > Given that, would it make sense to
> > change this line to something like:
> > 
> > if (type >= KMALLOC_PARTITION_START && type <= KMALLOC_PARTITION_END &&
> > 	!slab_tiny_enabled)
> 
> Maybe you could send a patch as it's a separate issue from the patchset?

Sure thing! I'll post it once vbabka's slab_tiny series lands.

-- 
Thanks,
Hao