From: Ran Xiaokai <ran.xiaokai@zte.com.cn>

Since commit a77d6d338685 ("mm/slab: place slabobj_ext metadata
in unused space within s->size"), the struct slabobj_ext array can
use slab leftover space or be embedded into the slub object to save
memory. In these cases, no extra kmalloc space is allocated for the
obj_exts array.

However, obj_full_size() always returns extra sizeof(struct obj_cgroup *)
bytes for every object, which leads to over-charging for slabs with
embedded obj_exts.

This series optimizes obj_full_size() to check whether obj_exts uses
slab leftover space or is embedded in the object. If so, only the object
size is charged. Otherwise, the extra obj_cgroup pointer space is also
charged.

Patch1 moves obj_exts_in_slab() definition to slab.h so it can be
       called from memcontrol.c.
Patch2 updates obj_full_size() to avoid over-charging.

Ran Xiaokai (2):
  mm/slab: move obj_exts_in_slab() definition to slab.h
  memcg: fix kmem over-charging for embedded obj_exts array

 mm/memcontrol.c | 19 ++++++++++++++-----
 mm/slab.h       | 19 +++++++++++++++++++
 mm/slub.c       | 19 -------------------
 3 files changed, 33 insertions(+), 24 deletions(-)

-- 
2.25.1

On Tue, Mar 10, 2026 at 11:38:02AM +0000, ranxiaokai627@163.com wrote:
> From: Ran Xiaokai <ran.xiaokai@zte.com.cn>
> 
> Since commit a77d6d338685 ("mm/slab: place slabobj_ext metadata
> in unused space within s->size"), the struct slabobj_ext array can
> use slab leftover space or be embedded into the slub object to save
> memory. In these cases, no extra kmalloc space is allocated for the
> obj_exts array.
> 
> However, obj_full_size() always returns extra sizeof(struct obj_cgroup *)
> bytes for every object, which leads to over-charging for slabs with
> embedded obj_exts.
> 
> This series optimizes obj_full_size() to check whether obj_exts uses
> slab leftover space or is embedded in the object. If so, only the object
> size is charged. Otherwise, the extra obj_cgroup pointer space is also
> charged.

Hi Ran,

At first look, I'm not sure if it's a good idea - although it's
allocated from wasted space, it's still memory that's needed to
charge objects.

But for "embedded into the slub object" case, yeah,
the metadata is charged twice, as it's already included in s->size.

Not having much expertise on memcg myself,
let's see what memcg folks say :)

> Patch1 moves obj_exts_in_slab() definition to slab.h so it can be
>        called from memcontrol.c.
> Patch2 updates obj_full_size() to avoid over-charging.
> 
> Ran Xiaokai (2):
>   mm/slab: move obj_exts_in_slab() definition to slab.h
>   memcg: fix kmem over-charging for embedded obj_exts array
> 
>  mm/memcontrol.c | 19 ++++++++++++++-----
>  mm/slab.h       | 19 +++++++++++++++++++
>  mm/slub.c       | 19 -------------------
>  3 files changed, 33 insertions(+), 24 deletions(-)
> 
> -- 
> 2.25.1
> 
> 
> 

-- 
Cheers,
Harry / Hyeonggon

On Wed, Mar 11, 2026 at 11:13:18AM +0900, Harry Yoo wrote:
> On Tue, Mar 10, 2026 at 11:38:02AM +0000, ranxiaokai627@163.com wrote:
> > From: Ran Xiaokai <ran.xiaokai@zte.com.cn>
> > 
> > Since commit a77d6d338685 ("mm/slab: place slabobj_ext metadata
> > in unused space within s->size"), the struct slabobj_ext array can
> > use slab leftover space or be embedded into the slub object to save
> > memory. In these cases, no extra kmalloc space is allocated for the
> > obj_exts array.
> > 
> > However, obj_full_size() always returns extra sizeof(struct obj_cgroup *)
> > bytes for every object, which leads to over-charging for slabs with
> > embedded obj_exts.
> > 
> > This series optimizes obj_full_size() to check whether obj_exts uses
> > slab leftover space or is embedded in the object. If so, only the object
> > size is charged. Otherwise, the extra obj_cgroup pointer space is also
> > charged.
> 
> Hi Ran,
> 
> At first look, I'm not sure if it's a good idea - although it's
> allocated from wasted space, it's still memory that's needed to
> charge objects.

Yes, I've been thinking about this as well.

For slabobj_ext that lives at the end of the whole slab, it seems reasonable to
charge it to the cgroup.

> 
> But for "embedded into the slub object" case, yeah,
> the metadata is charged twice, as it's already included in s->size.

While reading patch 2, I was also thinking about whether it would make sense to
call obj_exts_in_slab() on every object allocation and free for this case...

I wonder if we could use objext_flags to carry a bit of information about where
slabobj_ext is located.

-- 
Thanks,
Hao

On 3/11/26 04:06, Hao Li wrote:
> On Wed, Mar 11, 2026 at 11:13:18AM +0900, Harry Yoo wrote:
>> On Tue, Mar 10, 2026 at 11:38:02AM +0000, ranxiaokai627@163.com wrote:
>> > From: Ran Xiaokai <ran.xiaokai@zte.com.cn>
>> > 
>> > Since commit a77d6d338685 ("mm/slab: place slabobj_ext metadata
>> > in unused space within s->size"), the struct slabobj_ext array can
>> > use slab leftover space or be embedded into the slub object to save
>> > memory. In these cases, no extra kmalloc space is allocated for the
>> > obj_exts array.
>> > 
>> > However, obj_full_size() always returns extra sizeof(struct obj_cgroup *)
>> > bytes for every object, which leads to over-charging for slabs with
>> > embedded obj_exts.
>> > 
>> > This series optimizes obj_full_size() to check whether obj_exts uses
>> > slab leftover space or is embedded in the object. If so, only the object
>> > size is charged. Otherwise, the extra obj_cgroup pointer space is also
>> > charged.
>> 
>> Hi Ran,
>> 
>> At first look, I'm not sure if it's a good idea - although it's
>> allocated from wasted space, it's still memory that's needed to
>> charge objects.
> 
> Yes, I've been thinking about this as well.
> 
> For slabobj_ext that lives at the end of the whole slab, it seems reasonable to
> charge it to the cgroup.
> 
>> 
>> But for "embedded into the slub object" case, yeah,
>> the metadata is charged twice, as it's already included in s->size.
> 
> While reading patch 2, I was also thinking about whether it would make sense to
> call obj_exts_in_slab() on every object allocation and free for this case...
> 
> I wonder if we could use objext_flags to carry a bit of information about where
> slabobj_ext is located.

Uh maybe let's not complicate it and just drop obj_full_size() altogether
and just charge s->size? Just accept that allocating slab objects has some
overhead, we're not accounting all of it fully anyway. It shouldn't cause a
big difference in practice.