include/linux/memcontrol.h | 13 ---- mm/kfence/core.c | 5 +- mm/kfence/kfence_test.c | 2 +- mm/memcontrol.c | 41 ++++++----- mm/slab.h | 169 ++++++++++++++++++++++++++++++++++++--------- mm/slub.c | 162 +++++++++++++++++++++++++++---------------- 6 files changed, 267 insertions(+), 125 deletions(-)
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. 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.
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.
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.
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.
Only lightly tested, need to run at least some microbenchmarks to see if
the now somewhat more complicated access to objcg is visible or not.
Based on slab/for-next-fixes
Git branch: https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=b4/objext_split
Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
---
Vlastimil Babka (SUSE) (12):
mm/slab: skip kfence objects in allocation profiling
mm/slab: remove objs_per_slab()
mm: move struct slabobj_ext to mm/slab.h
mm/slab: make slab_obj_ext() determine object index
mm/slab: abstract slabobj_ext.objcg access
mm/slab: abstract slabobj_ext.ref access
mm/slab: replace slab.stride with obj_exts_in_object
mm/slab: change struct slabobj_ext to a union
mm/slab: introduce slab_obj_ext_has_codetag()
mm/slab: reduce slabobj_ext memory with allocation profiling disabled
mm/slab: add slab_needs_objcg() helper
mm/slab: stop allocating objcg pointers when unnecessary
include/linux/memcontrol.h | 13 ----
mm/kfence/core.c | 5 +-
mm/kfence/kfence_test.c | 2 +-
mm/memcontrol.c | 41 ++++++-----
mm/slab.h | 169 ++++++++++++++++++++++++++++++++++++---------
mm/slub.c | 162 +++++++++++++++++++++++++++----------------
6 files changed, 267 insertions(+), 125 deletions(-)
---
base-commit: d9e6a7623938968e3752b67e37eaff097e559a54
change-id: 20260714-b4-objext_split-da82426257d5
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. 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. > > 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. > > 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? > > 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? > > Only lightly tested, need to run at least some microbenchmarks to see if > the now somewhat more complicated access to objcg is visible or not. > > Based on slab/for-next-fixes > > Git branch: https://git.kernel.org/pub/scm/linux/kernel/git/vbabka/linux.git/log/?h=b4/objext_split > > Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org> > --- > Vlastimil Babka (SUSE) (12): > mm/slab: skip kfence objects in allocation profiling > mm/slab: remove objs_per_slab() > mm: move struct slabobj_ext to mm/slab.h > mm/slab: make slab_obj_ext() determine object index > mm/slab: abstract slabobj_ext.objcg access > mm/slab: abstract slabobj_ext.ref access > mm/slab: replace slab.stride with obj_exts_in_object > mm/slab: change struct slabobj_ext to a union > mm/slab: introduce slab_obj_ext_has_codetag() > mm/slab: reduce slabobj_ext memory with allocation profiling disabled > mm/slab: add slab_needs_objcg() helper > mm/slab: stop allocating objcg pointers when unnecessary > > include/linux/memcontrol.h | 13 ---- > mm/kfence/core.c | 5 +- > mm/kfence/kfence_test.c | 2 +- > mm/memcontrol.c | 41 ++++++----- > mm/slab.h | 169 ++++++++++++++++++++++++++++++++++++--------- > mm/slub.c | 162 +++++++++++++++++++++++++++---------------- > 6 files changed, 267 insertions(+), 125 deletions(-) > --- > base-commit: d9e6a7623938968e3752b67e37eaff097e559a54 > change-id: 20260714-b4-objext_split-da82426257d5 >
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
On Wed, Jul 15, 2026 at 8:29 PM Harry Yoo <harry@kernel.org> wrote: > > > > 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) 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
© 2016 - 2026 Red Hat, Inc.