From: Andrew Morton <akpm@linux-foundation.org>
To: "Barry Song (Xiaomi)" <baohua@kernel.org>
Cc: linux-mm@kvack.org, 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
Subject: Re: [PATCH v8 00/16] mm: mglru: fix swappiness behavior
Date: Fri, 13 Nov 2026 11:50:11 -0800 [thread overview]
Message-ID: <20261113115011.f90e267d58a9a88c513ae325@linux-foundation.org> (raw)
In-Reply-To: <20261113185541.70203-1-baohua@kernel.org>
On Sat, 14 Nov 2026 02:55:25 +0800 "Barry Song (Xiaomi)" <baohua@kernel.org> wrote:
> 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.
>
> ...
>
Thanks, I've updated mm.git's mm-new branch to this version. I expect
I'll advance the series into mm-unstable (hence linux-next) over the
weekend.
> 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!
Here's how v8 altered mm.git:
mm/vmscan.c | 34 ++++++++++++++++++++++++++--------
1 file changed, 26 insertions(+), 8 deletions(-)
--- a/mm/vmscan.c~b
+++ a/mm/vmscan.c
@@ -4034,8 +4034,6 @@ static void try_to_inc_min_seq(struct lr
/* see the comment on lru_gen_folio */
if (swappiness && swappiness <= MAX_SWAPPINESS) {
- unsigned long seq = lrugen->max_seq - MIN_NR_GENS;
-
if (min_seq[LRU_GEN_ANON] > seq && min_seq[LRU_GEN_FILE] < seq)
min_seq[LRU_GEN_ANON] = seq;
else if (min_seq[LRU_GEN_FILE] > seq && min_seq[LRU_GEN_ANON] < seq)
@@ -4246,7 +4244,13 @@ static bool lruvec_is_reclaimable(struct
if (mem_cgroup_below_min(NULL, memcg))
return false;
- if (!lruvec_is_sizable(lruvec, sc))
+ /*
+ * As in __alloc_pages_may_oom(), avoid triggering OOM for low-zone
+ * allocations. Also, defer the LRU size check until reclaim reaches
+ * a very low priority to avoid premature OOM.
+ */
+ if (sc->priority <= 1 && sc->reclaim_idx >= ZONE_NORMAL &&
+ !lruvec_is_sizable(lruvec, sc))
return false;
gen = lru_gen_from_seq(evictable_min_seq(min_seq, swappiness));
@@ -5220,6 +5224,13 @@ static bool try_to_shrink_lruvec(struct
bool need_rotate = false, should_age = false;
int swappiness = get_swappiness(lruvec, sc);
struct mem_cgroup *memcg = lruvec_memcg(lruvec);
+ /*
+ * Avoid aging the lagging type under extreme swappiness,
+ * as reclaim of the unpreferred type is disabled until
+ * DEF_PRIORITY / 2.
+ */
+ bool allow_no_populatable_age = (sc->priority <= DEF_PRIORITY / 2) ||
+ (swappiness > MIN_SWAPPINESS + 1 && swappiness < MAX_SWAPPINESS);
/*
* Proactive reclaim initiated by userspace for anonymous memory only.
@@ -5238,8 +5249,9 @@ static bool try_to_shrink_lruvec(struct
while (nr[LRU_GEN_ANON] > 0 || nr[LRU_GEN_FILE] > 0) {
unsigned long orig_file, orig_anon;
- DEFINE_MAX_SEQ(lruvec);
+ unsigned long max_seq;
bool no_populatable;
+ long scanned;
if (mem_cgroup_below_min(sc->target_mem_cgroup, memcg)) {
need_rotate = true;
@@ -5248,8 +5260,7 @@ static bool try_to_shrink_lruvec(struct
orig_anon = nr[LRU_GEN_ANON];
orig_file = nr[LRU_GEN_FILE];
- if (!evict_folio_lists(nr, lruvec, sc, swappiness, MIN_LRU_BATCH))
- break;
+ scanned = evict_folio_lists(nr, lruvec, sc, swappiness, MIN_LRU_BATCH);
if (should_abort_scan(lruvec, sc))
break;
@@ -5261,14 +5272,20 @@ static bool try_to_shrink_lruvec(struct
if (root_reclaim(sc) && should_age)
break;
- no_populatable = (nr[LRU_GEN_ANON] && nr[LRU_GEN_ANON] == orig_anon) ||
- (nr[LRU_GEN_FILE] && nr[LRU_GEN_FILE] == orig_file);
+ /* Limit no_populatable aging to once per try_to_shrink_lruvec() */
+ no_populatable = allow_no_populatable_age &&
+ ((nr[LRU_GEN_ANON] && nr[LRU_GEN_ANON] == orig_anon) ||
+ (nr[LRU_GEN_FILE] && nr[LRU_GEN_FILE] == orig_file));
+ allow_no_populatable_age &= !no_populatable;
+ max_seq = READ_ONCE((lruvec)->lrugen.max_seq);
if (should_run_aging(lruvec, max_seq, sc, swappiness, no_populatable)) {
trace_mm_mglru_aging(lruvec, sc, swappiness);
if (try_to_inc_max_seq(lruvec, max_seq, swappiness, false))
need_rotate = true;
should_age = true;
}
+ if (!scanned)
+ break;
cond_resched();
}
@@ -5965,6 +5982,7 @@ static ssize_t lru_gen_seq_write(struct
.may_writepage = true,
.may_unmap = true,
.may_swap = true,
+ .priority = DEF_PRIORITY,
.reclaim_idx = MAX_NR_ZONES - 1,
.gfp_mask = GFP_KERNEL,
.proactive = true,
_
prev parent reply other threads:[~2026-11-13 19:50 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-13 18:55 Barry Song (Xiaomi)
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 ` Andrew Morton [this message]
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=20261113115011.f90e267d58a9a88c513ae325@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--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
all inboxes | Powered by JetHome®