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

[Harry Yoo <harry@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1242 bytes --]



On 6/28/26 5:10 PM, Harry Yoo wrote:
> 
> 
> On 6/27/26 2:11 AM, Vlastimil Babka (SUSE) wrote:
>> Minimally I'd now want to only do that size bumping when allocation
>> profiling is enabled. Ideally that means both configured in and not booted
>> with "never".
>>
>> We probably should have done that already in 280ea9c3154b2.
> 
> I think we did already.
> 
> obj_exts allocation triggered by memcg has __GFP_ACCOUNT, kmalloc type
> is KMALLOC_CGROUP, and so is_kmalloc_normal() should return false?
> 
> Perhaps a comment above !is_kmalloc_normal() check would be nice.
> 
>> Because AFAIU
>> memcg-only obj_exts array don't have this issue
>> (or maybe they do have the > [1] issue? Harry?).
> 
> memcg-only obj_exts array doesn't have this issue and [1].
>> Because obj_exts are not accounted and so we can't allocate obj_exts
> from KMALLOC_CGROUP.

Oh god, I am confused again! Commit 8dafa9f5900c says it might have this
issue. However is_kmalloc_normal(s) == true detects that it might have
the problem when either 1) memory allocation profiling is enabled, or 2)
SLUB_TINY w/ __GFP_RECLAIMABLE|__GFP_ACCOUNT allocates accounted slab
objects from KMALLOC_NORMAL.

-- 
Cheers,
Harry / Hyeonggon


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]