[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <kr6fjny7aqni4habduj2uqfznusozkku3xeq62bjscb5ovwxog@ccgl3kxufmma>
Date: Thu, 24 Oct 2024 10:23:49 -0700
From: Shakeel Butt <shakeel.butt@...ux.dev>
To: Michal Hocko <mhocko@...e.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Johannes Weiner <hannes@...xchg.org>, Roman Gushchin <roman.gushchin@...ux.dev>,
Muchun Song <muchun.song@...ux.dev>, Hugh Dickins <hughd@...gle.com>, linux-mm@...ck.org,
cgroups@...r.kernel.org, linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
linux-doc@...r.kernel.org, Meta kernel team <kernel-team@...a.com>
Subject: Re: [RFC PATCH 3/3] memcg-v1: remove memcg move locking code
On Thu, Oct 24, 2024 at 11:16:52AM GMT, Michal Hocko wrote:
> On Wed 23-10-24 23:57:12, Shakeel Butt wrote:
> > The memcg v1's charge move feature has been deprecated. There is no need
> > to have any locking or protection against the moving charge. Let's
> > proceed to remove all the locking code related to charge moving.
> >
> > Signed-off-by: Shakeel Butt <shakeel.butt@...ux.dev>
> > ---
> > -/**
> > - * folio_memcg_lock - Bind a folio to its memcg.
> > - * @folio: The folio.
> > - *
> > - * This function prevents unlocked LRU folios from being moved to
> > - * another cgroup.
> > - *
> > - * It ensures lifetime of the bound memcg. The caller is responsible
> > - * for the lifetime of the folio.
> > - */
> > -void folio_memcg_lock(struct folio *folio)
> > -{
> > - struct mem_cgroup *memcg;
> > - unsigned long flags;
> > -
> > - /*
> > - * The RCU lock is held throughout the transaction. The fast
> > - * path can get away without acquiring the memcg->move_lock
> > - * because page moving starts with an RCU grace period.
> > - */
> > - rcu_read_lock();
>
> Is it safe to remove the implicit RCU?
Good question. I think it will be safe to keep the RCU in this patch and
in the followup examine each place and decide to remove RCU or not.
Thanks for the review.
Powered by blists - more mailing lists