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

[Suren Baghdasaryan]

On Wed, Jul 15, 2026 at 8:29 PM Harry Yoo <harry@xxxxxxxxxx> wrote:
>
>
>
> On 7/16/26 12:32 AM, Suren Baghdasaryan wrote:
> > On Wed, Jul 15, 2026 at 3:10 AM Vlastimil Babka (SUSE)
> > <vbabka@xxxxxxxxxx> 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)

Yeah and only when we detect that a cache that does not have
SLAB_ACCOUNT is used to allocate with __GFP_ACCOUNT set. Not sure
about the performance impact though...

>
> --
> Cheers,
> Harry / Hyeonggon