From: Johannes Weiner <hannes@cmpxchg.org>
To: Zhiguo Jiang <justinjiang@vivo.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
Chris Li <chrisl@kernel.org>, Michal Hocko <mhocko@suse.com>,
Kefeng Wang <wangkefeng.wang@huawei.com>,
Dan Schatzberg <schatzberg.dan@gmail.com>,
Yosry Ahmed <yosryahmed@google.com>,
Yue Zhao <findns94@gmail.com>, Hugh Dickins <hughd@google.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
opensource.kernel@vivo.com
Subject: Re: [PATCH v1 1/2] mm:vmscan: fix workingset eviction memcg issue
Date: Thu, 11 Jan 2024 08:41:25 -0500 [thread overview]
Message-ID: <20240111134125.GA390292@cmpxchg.org> (raw)
In-Reply-To: <20240111122451.682-2-justinjiang@vivo.com>
On Thu, Jan 11, 2024 at 08:24:50PM +0800, Zhiguo Jiang wrote:
> The parameter of target_memcg is NULL in workingset_eviction(), and
> the lruvec obtained by mem_cgroup_lruvec(target_memcg, pgdat) is always
> root_mem_cgroup->lruvec, rather than the lruvec of mem_cgroup where
> folio is actually located.
WTF? No!
/*
* The memory cgroup that hit its limit and as a result is the
* primary target of this reclaim invocation.
*/
struct mem_cgroup *target_mem_cgroup;
The cgroup that is stored in the eviction cookie is the one whose
limit triggered the reclaim cycle. This is often several levels above
the cgroups that own the pages. Subsequent refaults need to be
evaluated at the eviction level:
/*
* The activation decision for this folio is made at the level
* where the eviction occurred, as that is where the LRU order
* during folio reclaim is being determined.
*
* However, the cgroup that will own the folio is the one that
* is actually experiencing the refault event.
*/
> Fix target_memcg to the memcg obtained by folio_memcg(folio).
>
> Signed-off-by: Zhiguo Jiang <justinjiang@vivo.com>
Nacked-by: Johannes Weiner <hannes@cmpxchg.org>
Please take more time to read into the code you're proposing to
change. You made it sound like a trivial simplification, but this
totally screws up aging and pressure detection in containers.
next prev parent reply other threads:[~2024-01-11 13:41 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-11 12:24 [PATCH v1 0/2] *** SUBJECT HERE *** Zhiguo Jiang
2024-01-11 12:24 ` [PATCH v1 1/2] mm:vmscan: fix workingset eviction memcg issue Zhiguo Jiang
2024-01-11 13:41 ` Johannes Weiner [this message]
2024-01-11 14:15 ` zhiguojiang
2024-01-11 12:24 ` [PATCH v1 2/2] mm:vmscan: fix shrink sc parameters issue Zhiguo Jiang
2024-01-11 13:43 ` Johannes Weiner
2024-01-12 1:27 ` zhiguojiang
2024-01-11 12:51 ` [PATCH v1 0/2] *** SUBJECT HERE *** Christophe Leroy
2024-01-11 13:10 ` zhiguojiang
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=20240111134125.GA390292@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=chrisl@kernel.org \
--cc=david@redhat.com \
--cc=findns94@gmail.com \
--cc=hughd@google.com \
--cc=justinjiang@vivo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=opensource.kernel@vivo.com \
--cc=schatzberg.dan@gmail.com \
--cc=wangkefeng.wang@huawei.com \
--cc=willy@infradead.org \
--cc=yosryahmed@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