From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org,zhuhui@kylinos.cn,zhangbo56@xiaomi.com,
yuanchu@google.com,weixugc@google.com,wangzicheng@honor.com,
surenb@google.com,sidchintamaneni@gmail.com,shakeel.butt@linux.dev,
ryncsn@gmail.com,rppt@kernel.org,ridong.chen@linux.dev,qi.zheng@linux.dev,
mhocko@suse.com,lyugaofei@xiaomi.com,liuxiang.277@bytedance.com,
lianux.mm@gmail.com,liam@infradead.org,kunwu.chan@gmail.com,
hui.zhu@linux.dev,hannes@cmpxchg.org,chentao@kylinos.cn,baoquan.he@linux.dev,
baolin.wang@linux.alibaba.com,baohua@kernel.org,axelrasmussen@google.com,
kasong@tencent.com,akpm@linux-foundation.org
Subject: + mm-mglru-lift-the-forced-protection-of-reclaimer.patch added to mm-new branch
Date: Wed, 11 Nov 2026 17:17:10 -0800 [thread overview]
Message-ID: <20261112011711.2CBCE1F00A05@smtp.kernel.org> (raw)
The patch titled
Subject: mm/mglru: lift the forced protection of reclaimer
has been added to the -mm mm-new branch. Its filename is
mm-mglru-lift-the-forced-protection-of-reclaimer.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-mglru-lift-the-forced-protection-of-reclaimer.patch
This patch will later appear in the mm-new branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Note, mm-new is a provisional staging ground for work-in-progress
patches, and acceptance into mm-new is a notification for others take
notice and to finish up reviews. Please do not hesitate to respond to
review feedback and post updated versions to replace or incrementally
fixup patches in mm-new.
The mm-new branch of mm.git is not included in linux-next
If a few days of testing in mm-new is successful, the patch will me moved
into mm.git's mm-unstable branch, which is included in linux-next
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via various
branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there most days
------------------------------------------------------
From: Kairui Song <kasong@tencent.com>
Subject: mm/mglru: lift the forced protection of reclaimer
Date: Thu, 12 Nov 2026 07:25:51 +0800
When a type is drained down to MIN_NR_GENS gens, the reclaimer will
fail to make any progress on that type without aging.
However aging comes with a cost, and it will take time to finish. Even
if we do aging more proactively, when under great pressure, gens will
still be drained very fast so the new gens produced by aging can't catch
up with the consumption. With MIN_NR_GENS setting blocking the reclaim,
we will run into OOM. This OOM can be reproduced by the previous test
program [1] used for fixing another aging problem [2]. When running in
great pressure, certain workloads will keep seeing premature OOM with
MGLRU, and never see any OOM with classical LRU.
This might get worse if we implement async aging, or avoid hotness
inversion in aging, as they will slow down the aging process even more.
To fix this, let's first drop the get_nr_gens() == MIN_NR_GENS early
return and let the raised-priority scan bound cover max_seq itself.
Mapped folios will still survive as the rmap PTE check will keep them.
Unmapped cache folios may thrashing more when under great pressure,
which is really a problem that should be fixed with refault distance
and frequecy aware promotoin instead [3].
Link: https://lore.kernel.org/20261111232603.9934-5-baohua@kernel.org
Link: https://github.com/ryncsn/emm-test-project/tree/master/file-anon-mix-pressure [1]
Link: https://lore.kernel.org/linux-mm/20260428-mglru-reclaim-v7-0-02fabb92dc43@tencent.com/ [2]
Link: https://lore.kernel.org/linux-mm/20260502-mglru-fg-v1-0-913619b014d9@tencent.com/ [3]
Signed-off-by: Kairui Song <kasong@tencent.com>
Signed-off-by: Barry Song (Xiaomi) <baohua@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Kunwu Chan <kunwu.chan@gmail.com>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: Baoquan He <baoquan.he@linux.dev>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: <hui.zhu@linux.dev>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: wang lian <lianux.mm@gmail.com>
Cc: <liuxiang.277@bytedance.com>
Cc: <lyugaofei@xiaomi.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Qi Zheng <qi.zheng@linux.dev>
Cc: Ridong Chen <ridong.chen@linux.dev>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Kairui Song <ryncsn@gmail.com>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: wangzicheng <wangzicheng@honor.com>
Cc: Wei Xu <weixugc@google.com>
Cc: Yuanchu Xie <yuanchu@google.com>
Cc: Bo Zhang <zhangbo56@xiaomi.com>
Cc: Hui Zhu <zhuhui@kylinos.cn>
Cc: Siddharth Chintamaneni <sidchintamaneni@gmail.com>
Cc: Kunwu Chan <chentao@kylinos.cn>
---
mm/vmscan.c | 34 +++++++++++++++++++++++++---------
1 file changed, 25 insertions(+), 9 deletions(-)
--- a/mm/vmscan.c~mm-mglru-lift-the-forced-protection-of-reclaimer
+++ a/mm/vmscan.c
@@ -4679,7 +4679,7 @@ void lru_gen_reparent_memcg(struct mem_c
******************************************************************************/
static bool sort_folio(struct lruvec *lruvec, struct folio *folio, struct scan_control *sc,
- int min_gen, int tier_idx)
+ int min_gen, int max_gen, int tier_idx)
{
int gen = folio_lru_gen(folio);
int type = folio_is_file_lru(folio);
@@ -4696,12 +4696,22 @@ static bool sort_folio(struct lruvec *lr
if (!folio_evictable(folio))
return false;
- /* promoted */
+ /* promoted, or moved due to reparenting. */
if (gen != min_gen) {
list_move(&folio->lru, &lrugen->folios[gen][type][zone]);
return true;
}
+ /*
+ * We are reclaiming the last gen left. Folios in this gen can no
+ * longer be promoted or protected, so just isolate them. The one
+ * exception is lru_gen_reparent_memcg(), which is handled above.
+ */
+ if (min_gen == max_gen) {
+ VM_WARN_ON_ONCE(zone > sc->reclaim_idx);
+ return false;
+ }
+
/* protected */
if (tier > tier_idx || refs + workingset == BIT(LRU_REFS_WIDTH) + 1) {
gen = folio_inc_gen(lruvec, folio, min_gen);
@@ -4756,15 +4766,16 @@ static int scan_folios(unsigned long nr_
struct list_head *list, int *isolatedp)
{
int i;
- int gen;
enum node_stat_item item;
int sorted = 0;
int scanned = 0;
int isolated = 0;
int skipped = 0;
+ int gen, max_gen;
unsigned long min_seq;
unsigned long remaining = nr_to_scan;
struct lru_gen_folio *lrugen = &lruvec->lrugen;
+ DEFINE_MAX_SEQ(lruvec);
VM_WARN_ON_ONCE(nr_to_scan > MAX_LRU_BATCH);
VM_WARN_ON_ONCE(!list_empty(list));
@@ -4777,18 +4788,24 @@ static int scan_folios(unsigned long nr_
if (sc->priority == DEF_PRIORITY)
min_seq = lrugen->min_seq[type];
else
- min_seq = lruvec_populated_min_seq(lruvec, type, lrugen->max_seq - MIN_NR_GENS + 1);
-
- if (get_nr_gens(lruvec, type) == MIN_NR_GENS)
- return 0;
+ min_seq = lruvec_populated_min_seq(lruvec, type, lrugen->max_seq);
gen = lru_gen_from_seq(min_seq);
+ max_gen = lru_gen_from_seq(max_seq);
+
for (i = MAX_NR_ZONES; i > 0; i--) {
LIST_HEAD(moved);
int skipped_zone = 0;
int zone = (sc->reclaim_idx + i) % MAX_NR_ZONES;
struct list_head *head = &lrugen->folios[gen][type][zone];
+ /*
+ * If there is only one gen left, rotating the unreclaimable
+ * zone become meaningless, just skip them.
+ */
+ if (gen == max_gen && zone > sc->reclaim_idx)
+ continue;
+
while (!list_empty(head)) {
struct folio *folio = lru_to_folio(head);
int delta = folio_nr_pages(folio);
@@ -4799,8 +4816,7 @@ static int scan_folios(unsigned long nr_
VM_WARN_ON_ONCE_FOLIO(folio_zonenum(folio) != zone, folio);
scanned += delta;
-
- if (sort_folio(lruvec, folio, sc, gen, tier))
+ if (sort_folio(lruvec, folio, sc, gen, max_gen, tier))
sorted += delta;
else if (isolate_folio(lruvec, folio, sc)) {
list_add(&folio->lru, list);
_
Patches currently in -mm which might be from kasong@tencent.com are
mm-mglru-report-evictable-sizes-per-type.patch
mm-mglru-extract-lruvec_populated_min_seq-helper.patch
mm-mglru-reclaim-from-the-oldest-populated-gen.patch
mm-mglru-lift-the-forced-protection-of-reclaimer.patch
mm-mglru-skip-zones-above-reclaim_idx-instead-of-rotating-them.patch
mm-mglru-return-for-unavailable-anon-reclaim-earlier.patch
mm-mglru-balance-anon-and-file-scan-budget-by-refault-rate.patch
mm-mglru-lift-youngest-gen-protection-for-higher-priority.patch
next reply other threads:[~2026-11-12 1:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-12 1:17 Andrew Morton [this message]
-- strict thread matches above, loose matches on Subject: below --
2026-11-13 19:50 + mm-mglru-lift-the-forced-protection-of-reclaimer.patch added to mm-new branch 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=20261112011711.2CBCE1F00A05@smtp.kernel.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=chentao@kylinos.cn \
--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=liuxiang.277@bytedance.com \
--cc=lyugaofei@xiaomi.com \
--cc=mhocko@suse.com \
--cc=mm-commits@vger.kernel.org \
--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 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.