All of lore.kernel.org
 help / color / mirror / Atom feed
From: Guopeng Zhang <guopeng.zhang@linux.dev>
To: Johannes Weiner <hannes@cmpxchg.org>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Vlastimil Babka <vbabka@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: Michal Hocko <mhocko@kernel.org>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Muchun Song <muchun.song@linux.dev>, Harry Yoo <harry@kernel.org>,
	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: [PATCH] mm: memcg: fix slab over-accounting for in-object objcg metadata
Date: Wed, 12 Aug 2026 20:48:58 +0800	[thread overview]
Message-ID: <20260812124858.73487-1-guopeng.zhang@linux.dev> (raw)

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 *);
 }
 
@@ -3539,7 +3543,6 @@ bool __memcg_slab_post_alloc_hook(struct kmem_cache *s, struct list_lru *lru,
 				  gfp_t flags, unsigned int slab_alloc_flags,
 				  size_t size, void **p)
 {
-	size_t obj_size = obj_full_size(s);
 	struct obj_cgroup *objcg;
 	struct slab *slab;
 	size_t i;
@@ -3580,6 +3583,7 @@ bool __memcg_slab_post_alloc_hook(struct kmem_cache *s, struct list_lru *lru,
 		unsigned long obj_exts;
 		struct slabobj_ext *obj_ext;
 		struct obj_stock_pcp *stock;
+		size_t obj_size;
 
 		slab = virt_to_slab(p[i]);
 
@@ -3590,6 +3594,8 @@ bool __memcg_slab_post_alloc_hook(struct kmem_cache *s, struct list_lru *lru,
 				continue;
 		}
 
+		obj_size = obj_full_size(s, slab);
+
 		/*
 		 * if we fail and size is 1, memcg_alloc_abort_single() will
 		 * just free the object, which is ok as we have not assigned
@@ -3632,7 +3638,7 @@ bool __memcg_slab_post_alloc_hook(struct kmem_cache *s, struct list_lru *lru,
 void __memcg_slab_free_hook(struct kmem_cache *s, struct slab *slab,
 			    void **p, int objects, unsigned long obj_exts)
 {
-	size_t obj_size = obj_full_size(s);
+	size_t obj_size = obj_full_size(s, slab);
 
 	for (int i = 0; i < objects; i++) {
 		struct obj_cgroup *objcg;

base-commit: e7f630142df2afccce90555e4972e60008222311
-- 
2.43.0



             reply	other threads:[~2026-08-12 12:49 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12 12:48 Guopeng Zhang [this message]
2026-08-12 13:48 ` [PATCH] mm: memcg: fix slab over-accounting for in-object objcg metadata Tao Cui

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=20260812124858.73487-1-guopeng.zhang@linux.dev \
    --to=guopeng.zhang@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=harry@kernel.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.