Re: [PATCH 0/2] fix kmem over-charging for embedded obj_exts array
From: Hao Li
Date: Tue Mar 10 2026 - 23:07:12 EST
On Wed, Mar 11, 2026 at 11:13:18AM +0900, Harry Yoo wrote:
> On Tue, Mar 10, 2026 at 11:38:02AM +0000, ranxiaokai627@xxxxxxx wrote:
> > From: Ran Xiaokai <ran.xiaokai@xxxxxxxxxx>
> >
> > 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