From: "Barry Song (Xiaomi)" <baohua@kernel.org>
To: akpm@linux-foundation.org, linux-mm@kvack.org
Cc: axelrasmussen@google.com, baolin.wang@linux.alibaba.com,
baoquan.he@linux.dev, hannes@cmpxchg.org, hui.zhu@linux.dev,
kasong@tencent.com, kunwu.chan@gmail.com, liam@infradead.org,
lianux.mm@gmail.com, linux-kernel@vger.kernel.org,
liuxiang.277@bytedance.com, lyugaofei@xiaomi.com,
mhocko@kernel.org, mhocko@suse.com, qi.zheng@linux.dev,
ridong.chen@linux.dev, rppt@kernel.org, ryncsn@gmail.com,
shakeel.butt@linux.dev, surenb@google.com, wangzicheng@honor.com,
weixugc@google.com, yuanchu@google.com, zhangbo56@xiaomi.com,
zhuhui@kylinos.cn, sidchintamaneni@gmail.com,
"Barry Song (Xiaomi)" <baohua@kernel.org>
Subject: [PATCH v8 00/16] mm: mglru: fix swappiness behavior
Date: Sat, 14 Nov 2026 02:55:25 +0800 [thread overview]
Message-ID: <20261113185541.70203-1-baohua@kernel.org> (raw)
Classic LRU respects swappiness, while MGLRU only weakly
honors it when selecting the scan type. The fallback logic
can easily override the bias established by
get_type_to_scan(). As a result, swappiness has a much
smaller overall impact when changing from 1 to 200, as
shown by the data presented later in this cover letter.
In this patchset, patches 1-8 from Kairui introduce a model that uses
refaults to determine nr_to_scan[] for both file and anon in MGLRU.
For each reclaim operation, we calculate how many file and anon
folios to scan, similar to CLRU, rather than relying on
get_type_to_scan() and fallback mechanisms to decide what to
reclaim, which have proven rather unreliable in honoring swappiness.
This model also allows scanning and reclaiming from the two youngest
generations, including the youngest generation itself. This can help
resolve OOM situations[1] and reduce the need for aging.
As Kairui mentioned, the OOM reproducer was demonstrated
previously [2], and that series was merged in v7 [3].
The problem was largely alleviated as described, but not
completely fixed. Under higher memory pressure, the system
could still hit OOM. Before this series, Kairui could still
reproduce OOM after hundreds of iterations. With the fixing
patch in this series applied, the problem no longer occurs.
Patch 9 from Barry fixes a cold/hot inversion exacerbated by patches
1–8 (which also exists in mainline) and improves reclaim efficiency.
Patches 10-15 from Gaofei and Barry optimize aging based on folio
distribution imbalance and improve reclaim behavior at extreme
swappiness values such as 1 and 200.
Patch 16 from Bo Zhang addresses the GFP_NOIO issue in MGLRU.
After the patchset, the results track CLRU across the full swappiness
range (see table below), with more file scanning at low swappiness
and more anon scanning at high swappiness.
pgsteal_file
swappiness CLRU MGLRU MGLRU+patches
1 6,620,680 745,968 6,190,575
36 807,807 508,974 525,304
71 553,144 417,700 405,545
106 402,880 402,474 348,365
141 240,293 337,797 305,170
176 187,682 330,045 231,038
200 0 343,949 256
pgsteal_anon
swappiness CLRU MGLRU MGLRU+patches
1 4,436,199 2,671,934 5,103,813
36 2,858,117 3,032,747 3,134,511
71 3,042,392 2,827,735 3,170,171
106 3,292,622 3,184,314 3,225,293
141 3,612,869 2,999,000 3,590,478
176 3,827,154 3,134,127 3,873,163
200 13,825,283 3,269,753 14,399,074
pgscan_file
swappiness CLRU MGLRU MGLRU+patches
1 11,853,625 877,311 12,715,103
36 1,016,826 582,783 612,867
71 662,823 474,772 443,149
106 496,374 451,285 364,203
141 277,109 382,604 327,444
176 206,261 372,059 236,838
200 0 393,608 256
pgscan_anon
swappiness CLRU MGLRU MGLRU+patches
1 20,804,386 5,847,747 7,142,640
36 17,830,330 6,740,075 6,297,912
71 18,357,293 6,126,194 7,046,149
106 19,938,920 6,431,355 7,876,121
141 19,609,579 5,997,762 9,672,762
176 21,612,749 6,071,032 11,195,357
200 44,776,474 6,544,125 30,225,030
refault_file
swappiness CLRU MGLRU MGLRU+patches
1 6,523,070 667,302 6,103,539
36 722,110 431,585 448,161
71 477,062 340,241 331,108
106 327,610 324,747 272,266
141 161,827 265,959 228,015
176 115,551 258,515 172,882
200 0 268,049 212
refault_anon
swappiness CLRU MGLRU MGLRU+patches
1 867,728 552,829 1,415,594
36 419,635 657,745 668,238
71 536,299 611,345 672,096
106 580,742 693,689 728,319
141 706,151 639,850 817,954
176 706,499 685,086 949,643
200 4,693,850 733,273 5,475,622
With a normal swappiness setting (without extreme bias), I
see almost no noticeable performance difference between
the two versions.
For example, with `swappiness=60`, the average results
over 5 rounds are:
metric W/o patch W/ patch
real 1m49.273s 1m49.051s
user 25m33.186s 25m31.778s
sys 3m41.851s 3m40.721s
[1] https://github.com/ryncsn/emm-test-project/tree/master/file-anon-mix-pressure
[2] https://lore.kernel.org/all/20260318-mglru-reclaim-v1-0-2c46f9eb0508@tencent.com/
[3] https://lore.kernel.org/linux-mm/20260428-mglru-reclaim-v7-0-02fabb92dc43@tencent.com/
v8:
* Fixed Gaofei Lyu's name;
* for debugfs proactive reclaim, use DEF_PRIORITY;
* refine no-populatable aging (limit frequency, allow an aging
after eviction returns 0 scanned)
* refine "restrict eviction accounting to eligible zones" for
potential premature OOM;
* Collect Baolin's reviewed-by tag, thanks!
v7 link:
https://lore.kernel.org/linux-mm/20261111232603.9934-1-baohua@kernel.org/
v7:
* fix a build error of bisect and address some other sashiko minor comments;
* add no-populatable aging;
v6 link:
https://lore.kernel.org/linux-mm/20261110202025.25736-1-baohua@kernel.org/
v6:
* rebase on top of mm-new(a lot of conflicts due to recent active mglru
developments);
* only count eligible zones below sc->reclaim_idx for
lruvec_evictable_size() and lru_gen_imbalanced();
* GFP_NOIO further fixing by Bo Zhang, exclude unreclaimable type
in lruvec_evictable_size().
* Add Kunwu's reviewed-by, thanks!
* RFC v5 link:
https://lore.kernel.org/linux-mm/20261022220203.91911-1-baohua@kernel.org/
RFC v5:
* Remove the aging optimizations, which have been merged - thanks for Baolin,
Baoqun, Lian Wang, Kairui, Kunwu, Ridong reviewing on this;
* Add Kairui's model for determining nr_to_scan[] for both types.
* Fix cold/hot inversion for rejected folios - Barry.
* Improve and clean up imbalanced aging, and optimize extreme
swappiness values of 1 and 200 - Gaofei, Barry.
* Address the GFP_NOIO issue in MGLRU - Bo Zhang.
* RFC v4 link:
https://lore.kernel.org/linux-mm/20260812121658.69965-1-baohua@kernel.org/
RFC v4:
* Clean up isolate_folios() based on Baolin's feedback. Thanks!
* Further improve isolate_folios() and scan_folios(), including
handling of exhausted reclaim types.
* Add fixes and performance improvements to inc_min_seq(),
and reduce lock contention.
* Improve the handling of imbalanced aging and remaining
generation-based aging.
* RFC v3 link:
https://lore.kernel.org/linux-mm/20260731083843.37811-1-baohua@kernel.org/
RFC v3:
- Added Ridong's patch of improving isolate_folios() readability;
- for lru_gen_imbalanced(), apply some suggestions from Zicheng
and Kairui, considering lruvec size and use macro;
- drop "mm: mglru: only fall back when reclaim is running at high
priority"
- mitigate aging for balanced swappiess value(near middle 100)
as swappiness bias is less a concern for them; but slightly
increased aging overhead might not be good.
* RFC v2 link:
https://lore.kernel.org/linux-mm/20260726122123.7614-1-baohua@kernel.org/
RFC v2:
- Quickly address a few issues raised in the Sashiko comments so
reviewers can ignore v1 and review a cleaner version instead.
https://sashiko.dev/#/patchset/20260726012946.18684-1-baohua@kernel.org
Thanks, Sashiko!
Barry Song (Xiaomi) (5):
mm/mglru: Avoid placing rejected folios below populated gen
mm/mglru: Run aging when one type has no populatable folios
mm/mglru: Restrict eviction accounting to eligible zones
mm/mglru: Reduce LRU lock contention by shrinking folio batches in
inc_min_seq
mm/mglru: Make swappiness=1 file reclaim more aggressive
Bo Zhang (1):
mm/mglru: Avoid scan anon while swapcache is low for GFP_NOIO
allocation
Gaofei Lyu (2):
mm/mglru: Run aging when pages are rare outside the youngest gen
mm/mglru: Avoid prolonged anon reclaim with swappiness=200
Kairui Song (8):
mm/mglru: report evictable sizes per type
mm/mglru: extract lruvec_populated_min_seq() helper
mm/mglru: reclaim from the oldest populated gen
mm/mglru: lift the forced protection of reclaimer
mm/mglru: skip zones above reclaim_idx instead of rotating them
mm/mglru: return for unavailable anon reclaim earlier
mm/mglru: balance anon and file scan budget by refault rate
mm/mglru: lift youngest gen protection for higher priority
include/linux/mm_inline.h | 22 +-
mm/trace_vmscan.h | 4 +-
mm/vmscan.c | 516 +++++++++++++++++++++++++-------------
mm/vmscan.h | 5 +-
4 files changed, 366 insertions(+), 181 deletions(-)
--
2.39.3 (Apple Git-146)
next reply other threads:[~2026-11-13 18:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-13 18:55 Barry Song (Xiaomi) [this message]
2026-11-13 18:55 ` [PATCH v8 01/16] mm/mglru: report evictable sizes per type Barry Song (Xiaomi)
2026-11-13 18:55 ` [PATCH v8 02/16] mm/mglru: extract lruvec_populated_min_seq() helper Barry Song (Xiaomi)
2026-11-13 18:55 ` [PATCH v8 03/16] mm/mglru: reclaim from the oldest populated gen Barry Song (Xiaomi)
2026-11-13 18:55 ` [PATCH v8 04/16] mm/mglru: lift the forced protection of reclaimer Barry Song (Xiaomi)
2026-11-13 18:55 ` [PATCH v8 05/16] mm/mglru: skip zones above reclaim_idx instead of rotating them Barry Song (Xiaomi)
2026-11-13 18:55 ` [PATCH v8 06/16] mm/mglru: return for unavailable anon reclaim earlier Barry Song (Xiaomi)
2026-11-13 18:55 ` [PATCH v8 07/16] mm/mglru: balance anon and file scan budget by refault rate Barry Song (Xiaomi)
2026-11-13 18:55 ` [PATCH v8 08/16] mm/mglru: lift youngest gen protection for higher priority Barry Song (Xiaomi)
2026-11-13 18:55 ` [PATCH v8 09/16] mm/mglru: Avoid placing rejected folios below populated gen Barry Song (Xiaomi)
2026-11-13 18:55 ` [PATCH v8 10/16] mm/mglru: Run aging when pages are rare outside the youngest gen Barry Song (Xiaomi)
2026-11-13 18:55 ` [PATCH v8 11/16] mm/mglru: Run aging when one type has no populatable folios Barry Song (Xiaomi)
2026-11-13 18:55 ` [PATCH v8 12/16] mm/mglru: Restrict eviction accounting to eligible zones Barry Song (Xiaomi)
2026-11-13 18:55 ` [PATCH v8 13/16] mm/mglru: Reduce LRU lock contention by shrinking folio batches in inc_min_seq Barry Song (Xiaomi)
2026-11-13 18:55 ` [PATCH v8 14/16] mm/mglru: Avoid prolonged anon reclaim with swappiness=200 Barry Song (Xiaomi)
2026-11-13 18:55 ` [PATCH v8 15/16] mm/mglru: Make swappiness=1 file reclaim more aggressive Barry Song (Xiaomi)
2026-11-13 18:55 ` [PATCH v8 16/16] mm/mglru: Avoid scan anon while swapcache is low for GFP_NOIO allocation Barry Song (Xiaomi)
2026-11-13 19:50 ` [PATCH v8 00/16] mm: mglru: fix swappiness behavior Andrew Morton
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=20261113185541.70203-1-baohua@kernel.org \
--to=baohua@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baolin.wang@linux.alibaba.com \
--cc=baoquan.he@linux.dev \
--cc=hannes@cmpxchg.org \
--cc=hui.zhu@linux.dev \
--cc=kasong@tencent.com \
--cc=kunwu.chan@gmail.com \
--cc=liam@infradead.org \
--cc=lianux.mm@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liuxiang.277@bytedance.com \
--cc=lyugaofei@xiaomi.com \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=qi.zheng@linux.dev \
--cc=ridong.chen@linux.dev \
--cc=rppt@kernel.org \
--cc=ryncsn@gmail.com \
--cc=shakeel.butt@linux.dev \
--cc=sidchintamaneni@gmail.com \
--cc=surenb@google.com \
--cc=wangzicheng@honor.com \
--cc=weixugc@google.com \
--cc=yuanchu@google.com \
--cc=zhangbo56@xiaomi.com \
--cc=zhuhui@kylinos.cn \
/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