Re: [PATCH] mm/slub: serve slabobj_ext array from a strictly larger kmalloc cache

[Shakeel Butt]

On Fri, Jun 26, 2026 at 07:11:33PM +0200, Vlastimil Babka (SUSE) wrote:
[...]
> >> > Fix it structurally by removing cycles of every shape: serve the array
> >> > from a cache strictly larger than the one it describes whenever it would
> >> > otherwise come from the same or a smaller cache.  Every reference edge
> >> > then points from a smaller to a larger cache (here kmalloc-1k's array
> >> > moves to kmalloc-2k), so the relation is a DAG and cannot contain a cycle.
> >> 
> >> This will fix the problem.
> >> 
> >> But this will waste memory as we need smaller obj_exts array
> >> as the size gets larger.
> >> 
> >> We should probably create a new kmalloc type to avoid cycles instead?
> >> (needed only when memory profiling is enabled, though)
> >> 
> >> That would also prevent recursion even further.
> > 
> > Yes but I assume that would add kmem caches even for users not using memory
> > profiling. Anyways, I think that is a separate discussion. Am I understanding
> > correctly that you don't have any concerns with this approach?
> 
> Umm, the memory waste is a concern?
> 
> Minimally I'd now want to only do that size bumping when allocation
> profiling is enabled. Ideally that means both configured in and not booted
> with "never".
> 
> We probably should have done that already in 280ea9c3154b2. Because AFAIU
> memcg-only obj_exts array don't have this issue (or maybe they do have the
> [1] issue? Harry?). But if memcg-only should keep avoiding the same size
> bucket, it can keep what it was doing and only memalloc profiling would do
> the strictly larger thing.

memcg should not have this issue as normal kmalloc caches do not serve memcg
charged objects. 

So here we can do dedicated caches as Harry suggested or make this size bumping
very specialized as Vlastimil suggested. What do we want long term? Orthogonally
we do want this fix to be backported easily to older stable kernels. I will see
how does this narrowed down size bumping looks like.

> 
> Suren's input would be also nice to have.
> 
> Thanks!
> 
> [1] https://lore.kernel.org/oe-lkp/202601231457.f7b31e09-lkp@xxxxxxxxx
>