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

[Vlastimil Babka (SUSE)]

On 6/28/26 5:23 AM, Shakeel Butt wrote:
> On Sat, Jun 27, 2026 at 07:58:12PM -0700, Shakeel Butt wrote:
>> 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. 
> 
> I am wrong here as I went back and see d8df600b67d7.

(8dafa9f5900c upstream)

>>
>> 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

Maybe long term we make kmem_buckets unconditional and use that.

>> 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.
>>
> 
> BTW I think we need something like the following, right?
> 
> 	if (mem_alloc_profiling_enabled()) {
> 		if (obj_exts_cache->object_size <= s->object_size)
> 			return s->object_size + 1;
> 	} else {
> 		if (obj_exts_cache->object_size == s->object_size)
> 			return s->object_size + 1;
> 	}

Yeah.

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