From: "Barry Song (Xiaomi)" <baohua@kernel.org>
To: akpm@linux-foundation.org, linux-mm@kvack.org
Cc: axelrasmussen@google.com, david@kernel.org, hannes@cmpxchg.org,
kasong@tencent.com, linux-kernel@vger.kernel.org, ljs@kernel.org,
lyugaofei@xiaomi.com, mhocko@kernel.org, qi.zheng@linux.dev,
shakeel.butt@linux.dev, stevensd@chromium.org,
weixugc@google.com, yuanchu@google.com, chenridong@xiaomi.com,
zhangbo56@xiaomi.com, wangzicheng@honor.com, lianux.mm@gmail.com,
"Barry Song (Xiaomi)" <baohua@kernel.org>
Subject: [RFC PATCH v3 2/6] mm: mglru: let scan_folios() scan both reclaimable generations
Date: Fri, 31 Jul 2026 16:38:39 +0800 [thread overview]
Message-ID: <20260731083843.37811-3-baohua@kernel.org> (raw)
In-Reply-To: <20260731083843.37811-1-baohua@kernel.org>
When we have four generations, and scan_folios() exhausts the oldest
one while the second-oldest still contains reclaimable folios, the
current implementation doesn't move on to scan the second-oldest
generation. Instead, it returns, leaving that generation with no
chance to be scanned at the current sc->priority.
This doesn't seem right. Rather than breaking out and starting a
larger next iteration, let's let scan_folios() continue scanning the
second-oldest generation directly.
Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
---
mm/vmscan.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index ce027c271e9b..31947fa60f18 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -4718,6 +4718,7 @@ static int scan_folios(unsigned long nr_to_scan, struct lruvec *lruvec,
int skipped = 0;
unsigned long remaining = nr_to_scan;
struct lru_gen_folio *lrugen = &lruvec->lrugen;
+ unsigned long min_seq = lrugen->min_seq[type];
VM_WARN_ON_ONCE(nr_to_scan > MAX_LRU_BATCH);
VM_WARN_ON_ONCE(!list_empty(list));
@@ -4725,8 +4726,8 @@ static int scan_folios(unsigned long nr_to_scan, struct lruvec *lruvec,
if (get_nr_gens(lruvec, type) == MIN_NR_GENS)
return 0;
- gen = lru_gen_from_seq(lrugen->min_seq[type]);
-
+next_gen:
+ gen = lru_gen_from_seq(min_seq);
for (i = MAX_NR_ZONES; i > 0; i--) {
LIST_HEAD(moved);
int skipped_zone = 0;
@@ -4768,6 +4769,14 @@ static int scan_folios(unsigned long nr_to_scan, struct lruvec *lruvec,
break;
}
+ /*
+ * This generation is exhausted across all zones, but the scan
+ * target has not been reached yet. Continue with the next
+ * reclaimable generation.
+ */
+ if (i == 0 && ++min_seq + MIN_NR_GENS <= lrugen->max_seq)
+ goto next_gen;
+
item = PGSCAN_KSWAPD + reclaimer_offset(sc);
mod_lruvec_state(lruvec, item, isolated);
mod_lruvec_state(lruvec, PGREFILL, sorted);
--
2.34.1
next prev parent reply other threads:[~2026-07-31 8:39 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-31 8:38 [RFC PATCH v3 0/6] mm: mglru: fix swappiness behavior Barry Song (Xiaomi)
2026-07-31 8:38 ` [RFC PATCH v3 1/6] mm: mglru: prevent min_seq[type] from pointing to an empty generation Barry Song (Xiaomi)
2026-07-31 8:38 ` Barry Song (Xiaomi) [this message]
2026-07-31 8:38 ` [RFC PATCH v3 3/6] mm/mglru: improve readability of isolate_folios() Barry Song (Xiaomi)
2026-07-31 8:38 ` [RFC PATCH v3 4/6] mm: mglru: improve scan_folios() exhaustion detection Barry Song (Xiaomi)
2026-07-31 8:38 ` [RFC PATCH v3 5/6] mm: mglru: run aging when pages are severely imbalanced across gens Barry Song (Xiaomi)
2026-07-31 8:38 ` [RFC PATCH v3 6/6] 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=20260731083843.37811-3-baohua@kernel.org \
--to=baohua@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=chenridong@xiaomi.com \
--cc=david@kernel.org \
--cc=hannes@cmpxchg.org \
--cc=kasong@tencent.com \
--cc=lianux.mm@gmail.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=wangzicheng@honor.com \
--cc=weixugc@google.com \
--cc=yuanchu@google.com \
--cc=zhangbo56@xiaomi.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.