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 v2 1/5] mm: mglru: avoid scanning empty generations in scan_folios()
Date: Sun, 26 Jul 2026 20:21:19 +0800 [thread overview]
Message-ID: <20260726122123.7614-2-baohua@kernel.org> (raw)
In-Reply-To: <20260726122123.7614-1-baohua@kernel.org>
Commit 16b475d2ac3c ("mm/mglru: avoid reclaim type fall back when
isolation makes no progress") only falls back to the other type when
scanned == 0. However, I have frequently observed cases where
scanned > 0, but the older reclaimable generation becomes empty
after the first scan_folios(). As a result, the second
scan_folios() for the same type performs a redundant scan over an
empty generation.
We can avoid this by checking whether the reclaimable generation has
become empty when scanned < nr_to_scan and we still have fewer than
MIN_LRU_BATCH isolated folios after scan_folios().
Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
---
mm/vmscan.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 566c4e837c7d..babbce4bbfe8 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -4852,11 +4852,14 @@ static int isolate_folios(unsigned long nr_to_scan, struct lruvec *lruvec,
break;
}
/*
- * If scanned > 0 and isolated == 0, avoid falling back to the
- * other type, as this type remains sufficient. Falling back
- * too readily can disrupt the positive_ctrl_err() bias.
+ * If scanned >= nr_to_scan or isolated >= MIN_LRU_BATCH,
+ * avoid falling back to the other type. The preferred
+ * type is still reclaimable; otherwise, it would have
+ * already run out of reclaimable generations. Falling
+ * back too readily can disrupt the positive_ctrl_err()
+ * bias.
*/
- if (!scanned)
+ if (scanned < nr_to_scan && *isolated < MIN_LRU_BATCH)
type = !type;
}
--
2.39.3 (Apple Git-146)
next prev parent reply other threads:[~2026-07-26 12:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-26 12:21 [RFC PATCH v2 0/5] mm: mglru: fix swappiness behavior Barry Song (Xiaomi)
2026-07-26 12:21 ` Barry Song (Xiaomi) [this message]
2026-07-26 12:21 ` [RFC PATCH v2 2/5] mm: mglru: only fall back when reclaim is running at high priority Barry Song (Xiaomi)
2026-07-26 12:21 ` [RFC PATCH v2 3/5] mm: mglru: prevent min_seq[type] from pointing to an empty generation Barry Song (Xiaomi)
2026-07-26 12:21 ` [RFC PATCH v2 4/5] mm: mglru: run aging when pages are severely imbalanced across gens Barry Song (Xiaomi)
2026-07-26 12:21 ` [RFC PATCH v2 5/5] 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=20260726122123.7614-2-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 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.