Re: [PATCH RFC 00/12] mm/slab, alloc_tag: reduce obj_ext memory waste

[Harry Yoo <harry@kernel.org>]

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



On 7/16/26 12:32 AM, Suren Baghdasaryan wrote:
> On Wed, Jul 15, 2026 at 3:10 AM Vlastimil Babka (SUSE)
> <vbabka@kernel.org> wrote:
>>
>> The recent fixes for objext array handling inspired me to look into this
>> finally. It's been bothering me that the memory usage of struct
>> slabobj_ext depend only on config options and not whether the fields are
>> actually used.

+1 one more person bothered by this...

>> So with both CONFIG_MEMCG=y and
>> CONFIG_MEM_ALLOC_PROFILING=y there is always objcg field and codetag_ref
>> field. And thus:
>>
>> 1) Having memory allocation profiling config-enabled but not
>>    boot-enabled means wasted memory on unused codetag_refs. This makes
>>    it less suitable for a general distro config and the page allocator
>>    side doesn't suffer from this, only slab and percpu.
>>
>> 2) Complementary, with memory allocation profiling enabled, there are
>>    caches/slabs that don't need the objcg field, so memory is wasted on
>>    those.
> 
> It's funny because yesterday I started working on a prototype for the
> same optimization. But your patchset is much more mature, so I'll
> focus instead on reviewing it.

Ouch, a race condition!

>> This series should solve the point 1) fully for slab, pcpuobj_ext
>> handling can be perhaps improved similarly, haven't looked into that.
>>
>> For 2) it avoids allocating objcg fields for KMALLOC_NORMAL caches where
>> we know they are not necessary because kmalloc() with __GFP_ACCOUNT will
>> pick a KMALLOC_CGROUP type.

Unless KMALLOC_RECLAIM != KMALLOC_NORMAL! (yes, SLUB_TINY)

>> The named kmem_caches are tricky. They can be created with SLAB_ACCOUNT
>> and then we know objcg fields are always needed. But also they can be
>> created without SLAB_ACCOUNT and then some allocations have
>> __GFP_ACCOUNT and some not and we don't know that in advance.
> 
> Do you know how often this happens that a named cache with no
> SLAB_ACCOUNT is used for __GFP_ACCOUNT allocation?

Not sure about how often, but one thing I recall is xarray
(radix_tree_node cache), which decides to account the objects based on
xarray flags.

>> A possible future solution is to introduce e.g. SLAB_MAYBE_ACCOUNT, add
>> it to caches where we know __GFP_ACCOUNT is used, and only honour
>> __GFP_ACCOUNT for those, while warning for an unexpected usage
>> elsewhere.
>
> I wonder if for such caches we could create two separate caches, one
> serving __GFP_ACCOUNT and using extentions containing objcg and
> another one for non-__GFP_ACCOUNT with optimized extentions?

You mean transparently to users? (e.g., user thinks it has created
a single kmem_cache but actually there are two of them, multiplexed by
__GFP_ACCOUNT bit)

-- 
Cheers,
Harry / Hyeonggon

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