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

[Shakeel Butt <shakeel.butt@linux.dev>]

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@kernel.org> wrote:
> >>>
> >>>
> >>>
> >>> On 6/30/26 1:39 PM, Suren Baghdasaryan wrote:
> >>>> On Mon, Jun 29, 2026 at 9:38 PM Suren Baghdasaryan <surenb@google.com> 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.

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

> 
> > 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?
> 
> True, assuming that by 'self-amplifying' you meant this patch creates
> more kmalloc-8k objects, and also now kmalloc-8k wastes memory memory.
> 

I am not sure I understand what self-amplifying means here. Shouldn't 8k
allocations served by the same kmalloc-8k slab will share the obj_exts array?

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