On 6/30/26 11:52 PM, Suren Baghdasaryan wrote: > On Tue, Jun 30, 2026 at 7:36 AM Shakeel Butt 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 wrote: >>>>>> >>>>>> >>>>>> >>>>>> On 6/30/26 1:39 PM, Suren Baghdasaryan wrote: >>>>>>> On Mon, Jun 29, 2026 at 9:38 PM Suren Baghdasaryan 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