Re: [PATCH] mm: memcg: fix slab over-accounting for in-object objcg metadata
Harry Yoo <[email protected]>
| Newsgroups | org.kernel.vger.cgroups,org.kernel.vger.linux-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <aoF-MIwlfeI78Aox@ubuntu-vm-arm64> |
On Wed, Aug 12, 2026 at 08:48:58PM +0800, Guopeng Zhang wrote: > From: Guopeng Zhang <[email protected]> > > obj_full_size() adds the size of an obj_cgroup pointer to s->size to > account for slabobj_ext storage, which normally resides outside the > object. > > Since commit a77d6d338685 ("mm/slab: place slabobj_ext metadata in > unused space within s->size"), slabobj_ext can reside in object padding > already covered by s->size. The extra charge then accounts for the same > memory twice. > > The per-slab obj_exts_in_object bit introduced by commit b5bc35ace2c5 > ("mm/slab: replace slab.stride with obj_exts_in_object") identifies this > layout. Use it to omit the extra charge only for in-object metadata. > Unlike in-object metadata, slab-leftover and separately allocated metadata > are not covered by the per-object s->size charge, so retain the existing > charge for those cases. > > Reported-by: Ran Xiaokai <[email protected]> > Link: https://lore.kernel.org/all/[email protected]/ > Fixes: a77d6d338685 ("mm/slab: place slabobj_ext metadata in unused space within s->size") > Signed-off-by: Guopeng Zhang <[email protected]> > --- > mm/memcontrol.c | 14 ++++++++++---- > 1 file changed, 10 insertions(+), 4 deletions(-) > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > index d1312441a02b..aef480f46891 100644 > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -3526,12 +3526,16 @@ void obj_cgroup_uncharge(struct obj_cgroup *objcg, size_t size) > refill_obj_stock(objcg, size, true); > } > > -static inline size_t obj_full_size(struct kmem_cache *s) > +static inline size_t obj_full_size(struct kmem_cache *s, struct slab *slab) > { > /* > * For each accounted object there is an extra space which is used > - * to store obj_cgroup membership. Charge it too. > + * to store obj_cgroup membership. Charge it too, unless it is stored > + * in object padding already covered by s->size. > */ > + if (obj_exts_in_object(slab)) > + return s->size; > + > return s->size + sizeof(struct obj_cgroup *); From correctness terms of view, even this is not 100% correct because it doesn't account for the metadata for memory allocation profiling. But as Vlastimil questioned 5 months ago [1]: is it worth the complexity? Will simply charging s->size always make difference in practice? [1] https://lore.kernel.org/linux-mm/[email protected]