From: "Barry Song (Xiaomi)" <baohua@kernel.org>
To: akpm@linux-foundation.org, linux-mm@kvack.org
Cc: hannes@cmpxchg.org, david@kernel.org, mhocko@kernel.org,
qi.zheng@linux.dev, shakeel.butt@linux.dev, ljs@kernel.org,
kasong@tencent.com, axelrasmussen@google.com, yuanchu@google.com,
weixugc@google.com, linux-kernel@vger.kernel.org,
lyugaofei@xiaomi.com, stevensd@chromium.org,
"Barry Song (Xiaomi)" <baohua@kernel.org>
Subject: [RFC PATCH 0/4] mm: mglru: fix swappiness behavior
Date: Sun, 26 Jul 2026 09:29:42 +0800 [thread overview]
Message-ID: <20260726012946.18684-1-baohua@kernel.org> (raw)
The active/inactive LRU respects swappiness well. Anonymous page
scanning and reclamation increase roughly linearly with
swappiness, while file page scanning and reclamation decrease
accordingly.
For example, when swappiness reaches 200, both pgsteal_file and
pgscan_file drop to zero while building the kernel in a 1 GB
memcg. In contrast, MGLRU shows almost no change across different
swappiness values.
pgsteal_file
Swappiness LRU MGLRU
--------------------------------
1 10567455 763612
36 990706 480205
71 688170 415848
106 446294 386164
141 286307 359196
176 201733 351686
200 0 330093
pgsteal_anon
Swappiness LRU MGLRU
--------------------------------
1 4410548 2726362
36 2465268 2762859
71 2677908 2885124
106 2737227 2841796
141 2984276 3035015
176 3381338 2938302
200 13116359 3113499
pgscan_file
Swappiness LRU MGLRU
--------------------------------
1 17997223 923094
36 1325674 539571
71 852345 464222
106 538207 464477
141 357253 412277
176 217536 399446
200 0 375902
pgscan_anon
Swappiness LRU MGLRU
--------------------------------
1 31639423 5987136
36 23441521 5753224
71 26067110 6101780
106 25619448 5782919
141 26842088 6234264
176 29200021 5980292
200 62193924 6413125
This patchset respects the type selected by positive_ctrl_err(),
which uses swappiness as its gain. It does so by:
1. Avoiding premature fallback to the other type. Only fall back
when reclaim is running at high priority.
2. Running aging when the preferred type has few or no
reclaimable folios, so more folios of that type become
reclaimable.
With this patchset, swappiness starts to behave similarly to the
active/inactive LRU.
pgsteal_file
Swappiness LRU MGLRU MGLRU+Patch
-------------------------------------------------
1 10567455 763612 3507619
36 990706 480205 528781
71 688170 415848 478478
106 446294 386164 411632
141 286307 359196 375137
176 201733 351686 298586
200 0 330093 0
pgsteal_anon
Swappiness LRU MGLRU MGLRU+Patch
-------------------------------------------------
1 4410548 2726362 2876888
36 2465268 2762859 3022062
71 2677908 2885124 3129555
106 2737227 2841796 2974192
141 2984276 3035015 3092280
176 3381338 2938302 3353395
200 13116359 3113499 14348518
pgscan_file
Swappiness LRU MGLRU MGLRU+Patch
-------------------------------------------------
1 17997223 923094 5842416
36 1325674 539571 648111
71 852345 464222 569930
106 538207 464477 480767
141 357253 412277 431911
176 217536 399446 337768
200 0 375902 0
pgscan_anon
Swappiness LRU MGLRU MGLRU+Patch
-------------------------------------------------
1 31639423 5987136 4658593
36 23441521 5753224 5444726
71 26067110 6101780 5755804
106 25619448 5782919 5872415
141 26842088 6234264 6144096
176 29200021 5980292 6615500
200 62193924 6413125 22984986
Another possible approach is to decouple anonymous and file-backed
aging by maintaining separate max_seq values for each type. This
allows anonymous and file-backed memory to age and be reclaimed
independently, enabling the swappiness-preferred type to be reclaimed
more aggressively while allowing the other type to lag behind. This
approach has already been adopted by projects such as CachyOS [1] and
Chromium [2].
However, this approach requires substantial changes to MGLRU and
fundamentally alters its design by breaking the shared aging timeline
between anonymous and file-backed memory. This timeline is the
foundation for mechanisms such as the PID controller and the
min_ttl_ms thrashing protection.
That is why this patchset aims to fix the swappiness behavior
without fundamentally changing MGLRU's design, with minimal changes.
[1] https://github.com/firelzrd/re-swappiness
[2] https://chromium.googlesource.com/chromiumos/third_party/kernel/+log/929932351492d01f0aee37a0ac3be8c7bd88f80d
Barry Song (Xiaomi) (3):
mm: mglru: only fall back when reclaim is running at high priority
mm: mglru: do try_to_inc_min_seq if scanned==0
mm: mglru: run aging if the preferred type has no folios in
reclaimable gens
lyugaofei (1):
mm: mglru: run aging when pages are severely imbalanced across gens
mm/vmscan.c | 46 +++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 43 insertions(+), 3 deletions(-)
--
2.39.3 (Apple Git-146)
next reply other threads:[~2026-07-26 1:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-26 1:29 Barry Song (Xiaomi) [this message]
2026-07-26 1:29 ` [RFC PATCH 1/4] mm: mglru: only fall back when reclaim is running at high priority Barry Song (Xiaomi)
2026-07-26 1:29 ` [RFC PATCH 2/4] mm: mglru: do try_to_inc_min_seq if scanned==0 Barry Song (Xiaomi)
2026-07-26 1:29 ` [RFC PATCH 3/4] mm: mglru: run aging when pages are severely imbalanced across gens Barry Song (Xiaomi)
2026-07-26 1:29 ` [RFC PATCH 4/4] mm: mglru: run aging if the preferred type has no folios in reclaimable gens Barry Song (Xiaomi)
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=20260726012946.18684-1-baohua@kernel.org \
--to=baohua@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kasong@tencent.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=lyugaofei@xiaomi.com \
--cc=mhocko@kernel.org \
--cc=qi.zheng@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=stevensd@chromium.org \
--cc=weixugc@google.com \
--cc=yuanchu@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