All of lore.kernel.org
 help / color / mirror / Atom feed
From: Muchun Song <muchun.song@linux.dev>
To: bingfangguo@tencent.com
Cc: 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>, Bingfang Guo <bfguo@icloud.com>
Subject: Re: [PATCH RFC v2 3/6] mm/memcg: pass the id itself instead of memcg for putting ID
Date: Sat, 5 Sep 2026 18:01:44 +0800	[thread overview]
Message-ID: <29c98946-cb26-4b1e-8a95-fbdc9c9671ad@linux.dev> (raw)
In-Reply-To: <20260901-bingfangguo-memcgid-rework-v2-3-8edd7f7a7251@tencent.com>



On 2026/9/1 16:58, Bingfang Guo via B4 Relay wrote:
> From: Bingfang Guo <bingfangguo@tencent.com>
>
> Swap uncharge knows the memcg only by its private id, and the id can
> outlive the memcg it used to belong to after we rebind memcgid to
> objcgs.  Make mem_cgroup_private_id_put() take the id and resolve the
> memcg containing the refcount internally, and keep the underlying
> __mem_cgroup_private_id_put() for the offline path that still holds a
> memcg pointer.
>
> In the uncharge path, the memcg pointer will have to be read from the
> xarray twice, but we'll fix that later by returning the memcg from the
> put path, so the uncharge path can obtain a reference in the same step.
>
> Signed-off-by: Bingfang Guo <bingfangguo@tencent.com>
> ---
>   mm/memcontrol.c | 17 ++++++++++++++---
>   1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index ecb4fb07d7735..048c9bb0fad79 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -4038,7 +4038,7 @@ static void mem_cgroup_private_id_remove(struct mem_cgroup *memcg)
>   	}
>   }
>   
> -static inline void mem_cgroup_private_id_put(struct mem_cgroup *memcg, unsigned int n)
> +static void __mem_cgroup_private_id_put(struct mem_cgroup *memcg, unsigned int n)
>   {
>   	if (refcount_sub_and_test(n, &memcg->id.ref)) {
>   		mem_cgroup_private_id_remove(memcg);
> @@ -4048,9 +4048,19 @@ static inline void mem_cgroup_private_id_put(struct mem_cgroup *memcg, unsigned
>   	}
>   }
>   
> +static void mem_cgroup_private_id_put(unsigned short id, unsigned int n)
> +{
> +	struct mem_cgroup *memcg;
> +
> +	rcu_read_lock();
> +	memcg = mem_cgroup_from_private_id(id);
> +	__mem_cgroup_private_id_put(memcg, n);
> +	rcu_read_unlock();
> +}

To me, the direction of this change makes sense. At the same
time, I would also suggest applying a similar change to the get
function, for example: change mem_cgroup_private_id_get_online
to:

     unsigned short mem_cgroup_private_id_get(struct mem_cgroup *memcg,
                                              unsigned int n);

Have it return a private ID. That way, I think the two interfaces
look much more symmetrical overall.

Based on this change, it should be easier to implement the
direction of my last suggestion in Patch 5.

Muchun,
Thanks.

> +
>   static void mem_cgroup_private_id_kill(struct mem_cgroup *memcg)
>   {
> -	mem_cgroup_private_id_put(memcg, 1);
> +	__mem_cgroup_private_id_put(memcg, 1);
>   }
>   
>   struct mem_cgroup *mem_cgroup_private_id_get_online(struct mem_cgroup *memcg, unsigned int n)
> @@ -5815,9 +5825,10 @@ void __mem_cgroup_uncharge_swap(unsigned short id, unsigned int nr_pages)
>   				page_counter_uncharge(&memcg->swap, nr_pages);
>   		}
>   		mod_memcg_state(memcg, MEMCG_SWAP, -nr_pages);
> -		mem_cgroup_private_id_put(memcg, nr_pages);
> +		mem_cgroup_private_id_put(id, nr_pages);
>   	}
>   	rcu_read_unlock();
> +
>   }
>   
>   long mem_cgroup_get_nr_swap_pages(struct mem_cgroup *memcg)
>


  reply	other threads:[~2026-09-05 10:01 UTC|newest]

Thread overview: 29+ 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:57 ` Bingfang Guo
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   ` Bingfang Guo
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  8:58   ` Bingfang Guo
2026-09-01 16:15   ` Bingfang Guo
2026-09-05  7:12   ` Muchun Song
2026-09-05 19:35     ` Bingfang Guo
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-01  8:58   ` Bingfang Guo
2026-09-05 10:01   ` Muchun Song [this message]
2026-09-05 19:48     ` Bingfang Guo
2026-09-07 12:08     ` 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  8:58   ` Bingfang Guo
2026-09-01 15:58   ` Bingfang Guo
2026-09-05  7:28   ` Muchun Song
2026-09-05 19:36     ` Bingfang Guo
2026-09-07  7:10       ` Muchun Song
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-01  8:58   ` Bingfang Guo
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-01  8:58   ` Bingfang Guo
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=29c98946-cb26-4b1e-8a95-fbdc9c9671ad@linux.dev \
    --to=muchun.song@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=baohua@kernel.org \
    --cc=bfguo@icloud.com \
    --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=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 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.