[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YHB6FQ40Xn9E4psq@cmpxchg.org>
Date: Fri, 9 Apr 2021 12:00:21 -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 04/18] mm: memcontrol: simplify
lruvec_holds_page_lru_lock
On Fri, Apr 09, 2021 at 08:29:45PM +0800, Muchun Song wrote:
> We already have a helper lruvec_memcg() to get the memcg from lruvec, we
> do not need to do it ourselves in the lruvec_holds_page_lru_lock(). So use
> lruvec_memcg() instead. And if mem_cgroup_disabled() returns false, the
> page_memcg(page) (the LRU pages) cannot be NULL. So remove the odd logic
> of "memcg = page_memcg(page) ? : root_mem_cgroup". And use lruvec_pgdat
> to simplify the code. We can have a single definition for this function
> that works for !CONFIG_MEMCG, CONFIG_MEMCG + mem_cgroup_disabled() and
> CONFIG_MEMCG.
>
> Signed-off-by: Muchun Song <songmuchun@...edance.com>
Looks good to me.
Acked-by: Johannes Weiner <hannes@...xchg.org>
If you haven't done so yet, please make sure to explicitly test with
all three config combinations, just because the dummy abstractions for
memcg disabled or compiled out tend to be paper thin and don't always
behave the way you might expect when you do more complicated things.
Something like
boot
echo sparsefile >/dev/null (> ram size to fill memory and reclaim)
echo 1 >/proc/sys/vm/compact_memory
should exercise this new function in a couple of important scenarios.
Powered by blists - more mailing lists