[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YHCAb1cZFuqLiy6r@cmpxchg.org>
Date: Fri, 9 Apr 2021 12:27:27 -0400
From: Johannes Weiner <hannes@...xchg.org>
To: Muchun Song <songmuchun@...edance.com>
Cc: guro@...com, mhocko@...nel.org, akpm@...ux-foundation.org,
shakeelb@...gle.com, vdavydov.dev@...il.com,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
duanxiongchun@...edance.com, fam.zheng@...edance.com,
bsingharora@...il.com, shy828301@...il.com,
alex.shi@...ux.alibaba.com
Subject: Re: [RFC PATCH v2 05/18] mm: memcontrol: simplify the logic of objcg
pinning memcg
On Fri, Apr 09, 2021 at 08:29:46PM +0800, Muchun Song wrote:
> The obj_cgroup_release() and memcg_reparent_objcgs() are serialized by
> the css_set_lock. We do not need to care about objcg->memcg being
> released in the process of obj_cgroup_release(). So there is no need
> to pin memcg before releasing objcg. Remove those pinning logic to
> simplfy the code.
Hm yeah, it's not clear to me why inherited objcgs pinned the memcg in
the first place, since they are reparented during memcg deletion and
therefor have no actual impact on the memcg's lifetime.
> There are only two places that modifies the objcg->memcg. One is the
> initialization to objcg->memcg in the memcg_online_kmem(), another
> is objcgs reparenting in the memcg_reparent_objcgs(). It is also
> impossible for the two to run in parallel. So xchg() is unnecessary
> and it is enough to use WRITE_ONCE().
Good catch.
> Signed-off-by: Muchun Song <songmuchun@...edance.com>
Looks like a nice cleanup / simplification:
Acked-by: Johannes Weiner <hannes@...xchg.org>
Powered by blists - more mailing lists