From: Zhongkun He <hezhongkun.hzk@bytedance.com>
To: akpm@linux-foundation.org
Cc: mhocko@suse.com, hannes@cmpxchg.org, muchun.song@linux.dev,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Zhongkun He <hezhongkun.hzk@bytedance.com>
Subject: [PATCH] mm: vmscan: skip the file folios in proactive reclaim if swappiness is MAX
Date: Wed, 12 Mar 2025 17:43:37 +0800 [thread overview]
Message-ID: <20250312094337.2296278-1-hezhongkun.hzk@bytedance.com> (raw)
With this patch 'commit <68cd9050d871> ("mm: add swappiness= arg to
memory.reclaim")', we can submit an additional swappiness=<val> argument
to memory.reclaim. It is very useful because we can dynamically adjust
the reclamation ratio based on the anonymous folios and file folios of
each cgroup. For example,when swappiness is set to 0, we only reclaim
from file pages.
However,we have also encountered a new issue: when swappiness is set to
the MAX_SWAPPINESS, it may still only reclaim file folios. This is due
to the knob of cache_trim_mode, which depends solely on the ratio of
inactive folios, regardless of whether there are a large number of cold
folios in anonymous folio list.
So, we hope to add a new control logic where proactive memory reclaim only
reclaims from anonymous folios when swappiness is set to MAX_SWAPPINESS.
For example, something like this:
echo "2M swappiness=200" > /sys/fs/cgroup/memory.reclaim
will perform reclaim on the rootcg with a swappiness setting of 200 (max
swappiness) regardless of the file folios. Users have a more comprehensive
view of the application's memory distribution because there are many
metrics available.
With this patch, the swappiness argument of memory.reclaim has a more
precise semantics: 0 means reclaiming only from file pages, while 200
means reclaiming just from anonymous pages.
Signed-off-by: Zhongkun He <hezhongkun.hzk@bytedance.com>
---
mm/vmscan.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index c767d71c43d7..f4312b41e0e0 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2438,6 +2438,16 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc,
goto out;
}
+ /*
+ * Do not bother scanning file folios if the memory reclaim
+ * invoked by userspace through memory.reclaim and the
+ * swappiness is MAX_SWAPPINESS.
+ */
+ if (sc->proactive && (swappiness == MAX_SWAPPINESS)) {
+ scan_balance = SCAN_ANON;
+ goto out;
+ }
+
/*
* Do not apply any pressure balancing cleverness when the
* system is close to OOM, scan both anon and file equally
--
2.39.5
next reply other threads:[~2025-03-12 9:43 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-12 9:43 Zhongkun He [this message]
2025-03-12 22:36 ` Andrew Morton
2025-03-13 2:29 ` [External] " Zhongkun He
2025-03-12 23:16 ` Johannes Weiner
2025-03-13 2:34 ` [External] " Zhongkun He
2025-03-14 0:17 ` Yosry Ahmed
2025-03-14 2:20 ` [External] " Zhongkun He
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=20250312094337.2296278-1-hezhongkun.hzk@bytedance.com \
--to=hezhongkun.hzk@bytedance.com \
--cc=akpm@linux-foundation.org \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
/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