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

[Suren Baghdasaryan]

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.

>
> >
> > ...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'll also give it some thought to see if there is maybe a different
way to fix this that would be easy to backport.

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