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

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

On 6/26/26 18:49, Shakeel Butt wrote:
> On Fri, Jun 26, 2026 at 01:22:09PM +0900, Harry Yoo wrote:
>> 
>> Hi Shakeel,
>> 
> 
> [...]
> 
>> > What happened: a KMALLOC_NORMAL slab's obj_exts array (used by allocation
>> > profiling / memcg accounting) is itself kmalloc()'d from a KMALLOC_NORMAL
>> > cache,
>> 
>> Usually KMALLOC_NORMAL caches don't need obj_exts array, but yes,
>> this could happen if memory allocation profiling is enabled.
> 
> Yes, we have enabled memory allocation profiling fleet wide.
> 
> [...]
> 
>> 
>> > 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.

Suren's input would be also nice to have.

Thanks!

[1] https://lore.kernel.org/oe-lkp/202601231457.f7b31e09-lkp@intel.com

>> 
>> > No slab can be self- or cross-pinned, the tear-down recursion is bounded
>> > by the number of kmalloc size classes (it terminates at the large-kmalloc
>> > path, which carries no obj_exts), and profiling/accounting coverage is
>> > unchanged - the array is still allocated, only relocated.
>> > 
>> > Reproduced on next-20260623 at the same geometry: churning
>> > kmalloc-512/kmalloc-1k under vm.mem_profiling and then shrinking leaves
>> > kmalloc-512 with thousands of unreclaimable objects without this patch
>> > (8056) and at baseline with it (847).
>> > 
>> > Fixes: 4b8736964640 ("mm/slab: add allocation accounting into slab allocation and free paths")
>> 
>> Perhaps Cc: stable? v6.12 and v6.18 are affected.
> 
> Ack.
> 
> [...]
> 
>> > -	if (s->object_size == obj_exts_cache->object_size)
>> > -		return obj_exts_cache->object_size + 1;
>> > +	/* compare object_size, not the cache pointer (partitioned kmalloc caches) */
>> 
>> This comment is no longer relevant, by the way.
>> 
>> "compare object_size instead of cache pointers because there can be
>>  multiple caches of the same size" doesn't apply anymore.
>> 
> 
> I will remove the comment in next version.
> 
> Thanks for the review.
> 
>> > +	if (obj_exts_cache->object_size <= s->object_size)
>> > +		return s->object_size + 1;
>> >  
>> >  	return sz;
>> >  }
>> 
>> -- 
>> Cheers,
>> Harry / Hyeonggon
> 
> 
>