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

[Harry Yoo]

On 6/30/26 11:52 PM, Suren Baghdasaryan wrote:
> On Tue, Jun 30, 2026 at 7:36 AM Shakeel Butt <shakeel.butt@xxxxxxxxx> wrote:
>>
>> On Tue, Jun 30, 2026 at 04:03:30PM +0900, Harry Yoo wrote:
>>>
>>>
>>> On 6/30/26 3:12 PM, Vlastimil Babka (SUSE) wrote:
>>>> 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.
>>>
>>> Right.
>>
>> Yeah I should have given more thought on wastage.
> 
> Ugh! I didn't realize the wastage was that high.

Ouch!

>>> ...which is why I was assuming either the KMALLOC_TYPE or SLAB_BUCKETS
>>> approach would be backported as a follow-up. Err, should have
>>> communicated clearly, apologies.
>>
>> Harry, do you want to take a stab at prototyping these? If these look simple
>> enough, we can request backports of this.

Ack, let's see what would be the minimal changes to resolve this.

> I'll also give it some thought to see if there is maybe a different
> way to fix this that would be easy to backport.

Thanks, let's discuss!

>>>> 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.
>>>
>>> I think a key factor is when it's enabled in production.
>>>
>>> kconfigs says Android selects MEM_ALLOC_PROFILING, but not
>>> MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT.
>>>
>>> I assumed that turning it on by default in the entire fleet
>>> would be bit hard to justify... (please correct me,
>>> if it's not the case)
>>
>> Actually we have memory profiling enabled by default across Meta fleet. So, the
>> issue is very real.

I see, thanks for clarifying.

>> At the moment, we are seeing this issue on a specific
>> type of machine and we have disabled memory profiling for those machines.
>> Internally we did discuss to simply disable memory allocation profiling for
>> kmalloc-normal caches but to me that was a big hammer and thus suggested the
>> current approach.

-- 
Cheers,
Harry / Hyeonggon

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature