All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harry Yoo <harry@kernel.org>
To: Guopeng Zhang <guopeng.zhang@linux.dev>
Cc: Johannes Weiner <hannes@cmpxchg.org>,
	 Roman Gushchin <roman.gushchin@linux.dev>,
	Vlastimil Babka <vbabka@kernel.org>,
	 Andrew Morton <akpm@linux-foundation.org>,
	Michal Hocko <mhocko@kernel.org>,
	 Shakeel Butt <shakeel.butt@linux.dev>,
	Muchun Song <muchun.song@linux.dev>,
	cgroups@vger.kernel.org,  linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	 Guopeng Zhang <zhangguopeng@kylinos.cn>,
	Ran Xiaokai <ran.xiaokai@zte.com.cn>
Subject: Re: [PATCH] mm: memcg: fix slab over-accounting for in-object objcg metadata
Date: Sun, 16 Aug 2026 10:25:22 +0100	[thread overview]
Message-ID: <aoF-MIwlfeI78Aox@ubuntu-vm-arm64> (raw)
In-Reply-To: <20260812124858.73487-1-guopeng.zhang@linux.dev>

On Wed, Aug 12, 2026 at 08:48:58PM +0800, Guopeng Zhang wrote:
> From: Guopeng Zhang <zhangguopeng@kylinos.cn>
> 
> 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 <ran.xiaokai@zte.com.cn>
> Link: https://lore.kernel.org/all/20260310113804.245647-1-ranxiaokai627@163.com/
> Fixes: a77d6d338685 ("mm/slab: place slabobj_ext metadata in unused space within s->size")
> Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
> ---
>  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/e7ccb3b0-791e-4e01-86c3-65b613e3cc5a@kernel.org


      parent reply	other threads:[~2026-08-16  9:59 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12 12:48 [PATCH] mm: memcg: fix slab over-accounting for in-object objcg metadata Guopeng Zhang
2026-08-12 13:48 ` Tao Cui
2026-08-12 23:44 ` Shakeel Butt
2026-08-16  9:25 ` Harry Yoo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aoF-MIwlfeI78Aox@ubuntu-vm-arm64 \
    --to=harry@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=guopeng.zhang@linux.dev \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=muchun.song@linux.dev \
    --cc=ran.xiaokai@zte.com.cn \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=vbabka@kernel.org \
    --cc=zhangguopeng@kylinos.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.