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

[Vlastimil Babka (SUSE)]

On 6/30/26 07:29, Suren Baghdasaryan wrote:
> On Mon, Jun 29, 2026 at 9:42 PM Harry Yoo <harry@xxxxxxxxxx> wrote:
>>
>>
>>
>> On 6/30/26 1:39 PM, Suren Baghdasaryan wrote:
>> > On Mon, Jun 29, 2026 at 9:38 PM Suren Baghdasaryan <surenb@xxxxxxxxxx> wrote:
>> >>
>>
>> Ah, here I meant backporting either the kmalloc_flags()+KMALLOC_TYPE or
>> SLAB_BUCKETS approach.
>>
>> >> Yes, it's worth backporting, so we can merge Shakeel's change as is
>>
>> Right.
>>
>> >> and then once Vlastimil's patch is merged we can implement the new
>>
>> Vlastimil's patch has already landed mainline, by the way :)
> 
> Nice! I suggest posting Shakeel's patch CC'ing stable for backports
> and then following up with the fix using KMALLOC_TYPE. Vlastimil,
> WDYT?

Sounded like a plan, but then I realized I misunderstood the amount of the
wastage. E.g. on my system kmalloc-8k with 4 objects per slab would have
obj_ext size of 64, but now it's 16k? That's ridiculous. I think it will
even self-amplify to some extent? kmalloc-8 would have 512 objects per slab,
so its obj_ext is 8k. It will not recursively create an obj_ext for the
obj_ext, but other 8k allocation in the same kmalloc-8k slab could then
trigger it, right?

We could say it's for a debugging feature, but also it's running in
production fleets (and Android?), so probably not that easy to dismiss.
Sudden memory increase in a LTS due to this backport doesn't sound nice to me.

>>
>> >> KMALLOC_TYPE as a replacement.
>> >
>> > And Shakeel's patch is easily backportable.
>>
>> Yes, of course!
>>
>> --
>> Cheers,
>> Harry / Hyeonggon
>>