Linux cgroups development
 help / color / mirror / Atom feed
From: Bingfang Guo <bfguo@icloud.com>
To: Muchun Song <muchun.song@linux.dev>
Cc: bingfangguo@tencent.com, cgroups@vger.kernel.org,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	Johannes Weiner <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@kernel.org>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Andrew Morton <akpm@linux-foundation.org>,
	Dave Chinner <david@fromorbit.com>, Qi Zheng <qi.zheng@linux.dev>,
	Kairui Song <kasong@tencent.com>, Barry Song <baohua@kernel.org>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
	David Hildenbrand <david@kernel.org>,
	Lorenzo Stoakes <ljs@kernel.org>
Subject: Re: [PATCH RFC v2 2/6] mm/memcg: get memcgid reference only after swap charging success
Date: Sun, 6 Sep 2026 03:35:34 +0800	[thread overview]
Message-ID: <apxvBiaMbVnb6cvQ@BINGFANGGUO-MC0> (raw)
In-Reply-To: <a2fb9ea3-78dc-4bee-a64e-0928983961ad@linux.dev>

On Sat, Sep 05, 2026 at 03:12:19PM +0800, Muchun Song wrote:
> 
> 

Hi, Muchun!  Thanks for your insightful reviews!

> On 2026/9/1 16:58, Bingfang Guo via B4 Relay wrote:
> > From: Bingfang Guo <bingfangguo@tencent.com>
> > 
> > __mem_cgroup_try_charge_swap() pinned the memcg private id before the
> > swap counter was charged and had to undo the pin on the failure path.
> > Hold RCU lock for an extended period (which should be fine,
> > __memcg1_swapout() does this as well) so concurrent memcg release can
> > be avoided, and take the id reference to its online parent only after
> > charging has succeeded.
> > 
> > The failure path is now a plain return, and the id is only pinned for
> > entries that actually end up charged to swap.
> > 
> > Signed-off-by: Bingfang Guo <bingfangguo@tencent.com>
> > ---
> >   mm/memcontrol.c | 15 +++++++++------
> >   1 file changed, 9 insertions(+), 6 deletions(-)
> > 
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index 31cec9dde55f0..ecb4fb07d7735 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -5755,6 +5755,7 @@ int __mem_cgroup_try_charge_swap(struct folio *folio)
> >   	struct page_counter *counter;
> >   	struct mem_cgroup *memcg;
> >   	struct obj_cgroup *objcg;
> > +	unsigned short memcgid;
> >   	if (do_memsw_account())
> >   		return 0;
> > @@ -5772,22 +5773,24 @@ int __mem_cgroup_try_charge_swap(struct folio *folio)
> >   		return 0;
> >   	}
> > -	memcg = mem_cgroup_private_id_get_online(memcg, nr_pages);
> > -	/* memcg is pined by memcg ID. */
> > -	rcu_read_unlock();
> > +	while (memcg_is_dying(memcg))
> > +		memcg = parent_mem_cgroup(memcg);
> 
> Since we've already chosen to expand the scope of RCU holding, it
> seems we don't need to check whether the memcg is in a dying state
> here. The upcoming stats updates aren't really tied to whether the
> memcg is dying anyway, right? Why don't we just simplify the code?
> 
> Muchun,
> Thanks.

Yeah, indeed. Whether the memcg is dying doesn't make much
difference, and dying memcgs should be rare so walking up till
some online parent should be useless in most cases. And it does
seem a bit strange to do that here...

So I agree that removing the check would be better as well! I
will make the change in the next version.

Regards,
Bingfang

> >   	if (!mem_cgroup_is_root(memcg) &&
> >   	    !page_counter_try_charge(&memcg->swap, nr_pages, &counter)) {
> >   		memcg_memory_event(memcg, MEMCG_SWAP_MAX);
> >   		memcg_memory_event(memcg, MEMCG_SWAP_FAIL);
> > -		mem_cgroup_private_id_put(memcg, nr_pages);
> > +		rcu_read_unlock();
> >   		return -ENOMEM;
> >   	}
> >   	mod_memcg_state(memcg, MEMCG_SWAP, nr_pages);
> > +	memcg = mem_cgroup_private_id_get_online(memcg, nr_pages);
> > +	memcgid = mem_cgroup_private_id(memcg);
> > +	rcu_read_unlock();
> > +
> >   	ci = swap_cluster_get_and_lock(folio);
> > -	__swap_cgroup_set(ci, swp_cluster_offset(folio->swap), nr_pages,
> > -			  mem_cgroup_private_id(memcg));
> > +	__swap_cgroup_set(ci, swp_cluster_offset(folio->swap), nr_pages, memcgid);
> >   	swap_cluster_unlock(ci);
> >   	return 0;
> > 
> 


  reply	other threads:[~2026-09-05 19:35 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-01  8:57 [PATCH RFC v2 0/6] mm/memcg: move memcgid refcount to objcg to unpin dying memcgs Bingfang Guo via B4 Relay
2026-09-01  8:58 ` [PATCH RFC v2 1/6] mm/memcg: add a helper to kill the memcgid on offlining Bingfang Guo via B4 Relay
2026-09-01  8:58 ` [PATCH RFC v2 2/6] mm/memcg: get memcgid reference only after swap charging success Bingfang Guo via B4 Relay
2026-09-01 16:15   ` Bingfang Guo
2026-09-05  7:12   ` Muchun Song
2026-09-05 19:35     ` Bingfang Guo [this message]
2026-09-01  8:58 ` [PATCH RFC v2 3/6] mm/memcg: pass the id itself instead of memcg for putting ID Bingfang Guo via B4 Relay
2026-09-05 10:01   ` Muchun Song
2026-09-05 19:48     ` Bingfang Guo
2026-09-01  8:58 ` [PATCH RFC v2 4/6] mm/memcg: return the memcg when putting memcgid Bingfang Guo via B4 Relay
2026-09-01 15:58   ` Bingfang Guo
2026-09-05  7:28   ` Muchun Song
2026-09-05 19:36     ` Bingfang Guo
2026-09-01  8:58 ` [PATCH RFC v2 5/6] mm/memcg: move memcg private ID refcount to objcg Bingfang Guo via B4 Relay
2026-09-05  8:46   ` Muchun Song
2026-09-05 19:44     ` Bingfang Guo
2026-09-01  8:58 ` [PATCH RFC v2 6/6] mm/memcg: filter out reparented memcgs got from memcgid Bingfang Guo via B4 Relay
2026-09-02  3:53   ` Bingfang Guo
2026-09-05 12:18   ` Muchun Song
2026-09-05 19:45     ` Bingfang Guo

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=apxvBiaMbVnb6cvQ@BINGFANGGUO-MC0 \
    --to=bfguo@icloud.com \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=baohua@kernel.org \
    --cc=bingfangguo@tencent.com \
    --cc=cgroups@vger.kernel.org \
    --cc=david@fromorbit.com \
    --cc=david@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=kasong@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@kernel.org \
    --cc=muchun.song@linux.dev \
    --cc=qi.zheng@linux.dev \
    --cc=roman.gushchin@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=weixugc@google.com \
    --cc=yuanchu@google.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox