[PATCH 0/2] mm: vmscan: fix scan overshoot and ineligible folio scanning

[PATCH 0/2] mm: vmscan: fix scan overshoot and ineligible folio scanning

[Wupeng Ma]

shrink_lruvec() drives reclaim in SWAP_CLUSTER_MAX (32) chunks, but
isolate_lru_folios() may scan far more than that per call on a single
LRU.  The excess is never charged back, so shrink_lruvec() keeps
rescanning the same folios round after round.  When reclaim targets a
lower zone, the same scanner also keeps walking zone-ineligible folios
that can never satisfy the allocation, inflating nr_reclaimed into a
false progress that delays the OOM.

This series fixes both:

  [1/2] Charge the isolate overshoot against the scan quota so the
        next round skips already-scanned folios.
  [2/2] Stop scanning once too many zone-ineligible folios have been
        skipped, instead of force-isolating them.

Wupeng Ma (2):
  mm: vmscan: charge isolate overshoot against scan quota
  mm: vmscan: stop scanning ineligible folios after max_nr_skipped

 mm/vmscan.c | 48 +++++++++++++++++++++++++++++++++---------------
 1 file changed, 33 insertions(+), 15 deletions(-)

-- 
2.43.0

[PATCH 1/2] mm: vmscan: charge isolate overshoot against scan quota

[Wupeng Ma]

shrink_lruvec() charges the per-LRU budget nr[lru] in SWAP_CLUSTER_MAX
(32) chunks, but isolate_lru_folios() may scan far more per call: a
large folio can jump scan by many pages at once (a PMD-sized folio
counts 512), and a zone-ineligible LRU walks the whole list without
feeding scan back.  The overshoot is never refunded, so shrink_lruvec()
keeps charging only 32 per round and rescans the same folios.

Have isolate_lru_folios() record its scanned count in sc->nr_isolate_scanned
and let shrink_lruvec() subtract the overshoot from the remaining quota so
the next round skips already-scanned folios.  The field is reset to 0
before each shrink_list() call, as shrink_list() only reaches
isolate_lru_folios() on some paths (active + skipped_deactivate,
too_many_isolated stall bail out early); a stale value would otherwise
be charged.  The budget floor stays nr_to_scan via max() so an empty
LRU (sc->nr_isolate_scanned = 0) still advances and cannot deadlock.

Co-developed-by: Qiuhao Zhang <zhangqiuhao@huawei.com>
Signed-off-by: Qiuhao Zhang <zhangqiuhao@huawei.com>
Signed-off-by: Wupeng Ma <mawupeng1@huawei.com>
---
 mm/vmscan.c | 32 +++++++++++++++++++++-----------
 1 file changed, 21 insertions(+), 11 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 56708d1d2dfd5..147e74f9732d5 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -164,6 +164,9 @@ struct scan_control {
 	/* Incremented by the number of inactive pages that were scanned */
 	unsigned long nr_scanned;
 
+	/* Number of pages that were scanned from isolate_lru_folios() */
+	unsigned long nr_isolate_scanned;
+
 	/* Number of pages freed so far during a call to shrink_zones() */
 	unsigned long nr_reclaimed;
 
@@ -1673,7 +1676,6 @@ static __always_inline void update_lru_sizes(struct lruvec *lruvec,
  * @nr_to_scan:	The number of eligible pages to look through on the list.
  * @lruvec:	The LRU vector to pull pages from.
  * @dst:	The temp list to put pages on to.
- * @nr_scanned:	The number of pages that were scanned.
  * @sc:		The scan_control struct for this reclaim session
  * @lru:	LRU list id for isolating
  *
@@ -1681,8 +1683,7 @@ static __always_inline void update_lru_sizes(struct lruvec *lruvec,
  */
 static unsigned long isolate_lru_folios(unsigned long nr_to_scan,
 		struct lruvec *lruvec, struct list_head *dst,
-		unsigned long *nr_scanned, struct scan_control *sc,
-		enum lru_list lru)
+		struct scan_control *sc, enum lru_list lru)
 {
 	struct list_head *src = &lruvec->lists[lru];
 	unsigned long nr_taken = 0;
@@ -1766,7 +1767,7 @@ static unsigned long isolate_lru_folios(unsigned long nr_to_scan,
 			skipped += nr_skipped[zid];
 		}
 	}
-	*nr_scanned = total_scan;
+	sc->nr_isolate_scanned = total_scan;
 	trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan,
 				    total_scan, skipped, nr_taken, lru);
 	update_lru_sizes(lruvec, lru, nr_zone_taken);
@@ -2014,8 +2015,8 @@ static unsigned long shrink_inactive_list(unsigned long nr_to_scan,
 
 	lruvec_lock_irq(lruvec);
 
-	nr_taken = isolate_lru_folios(nr_to_scan, lruvec, &folio_list,
-				     &nr_scanned, sc, lru);
+	nr_taken = isolate_lru_folios(nr_to_scan, lruvec, &folio_list, sc, lru);
+	nr_scanned = sc->nr_isolate_scanned;
 
 	__mod_node_page_state(pgdat, NR_ISOLATED_ANON + file, nr_taken);
 	item = PGSCAN_KSWAPD + reclaimer_offset(sc);
@@ -2071,7 +2072,6 @@ static void shrink_active_list(unsigned long nr_to_scan,
 			       enum lru_list lru)
 {
 	unsigned long nr_taken;
-	unsigned long nr_scanned;
 	vm_flags_t vm_flags;
 	LIST_HEAD(l_hold);	/* The folios which were snipped off */
 	LIST_HEAD(l_active);
@@ -2085,12 +2085,11 @@ static void shrink_active_list(unsigned long nr_to_scan,
 
 	lruvec_lock_irq(lruvec);
 
-	nr_taken = isolate_lru_folios(nr_to_scan, lruvec, &l_hold,
-				     &nr_scanned, sc, lru);
+	nr_taken = isolate_lru_folios(nr_to_scan, lruvec, &l_hold, sc, lru);
 
 	__mod_node_page_state(pgdat, NR_ISOLATED_ANON + file, nr_taken);
 
-	mod_lruvec_state(lruvec, PGREFILL, nr_scanned);
+	mod_lruvec_state(lruvec, PGREFILL, sc->nr_isolate_scanned);
 
 	lruvec_unlock_irq(lruvec);
 
@@ -5920,10 +5919,21 @@ static void shrink_lruvec(struct lruvec *lruvec, struct scan_control *sc)
 		for_each_evictable_lru(lru) {
 			if (nr[lru]) {
 				nr_to_scan = min(nr[lru], SWAP_CLUSTER_MAX);
-				nr[lru] -= nr_to_scan;
 
+				sc->nr_isolate_scanned = 0;
 				nr_reclaimed += shrink_list(lru, nr_to_scan,
 							    lruvec, sc);
+				/*
+				 * isolate_lru_folios() may scan far more
+				 * than nr_to_scan when the LRU holds
+				 * ineligible folios (zone-skip) or large
+				 * folios. Charge that overshoot against the
+				 * remaining quota (clamped by min() so it
+				 * cannot go negative) so the next iteration
+				 * does not rescan the same skipped folios.
+				 */
+				nr[lru] -= min(nr[lru],
+					       max(nr_to_scan, sc->nr_isolate_scanned));
 			}
 		}
 
-- 
2.43.0

[PATCH 2/2] mm: vmscan: stop scanning ineligible folios after max_nr_skipped

[Wupeng Ma]

When reclaiming for a lower zone, isolate_lru_folios() accounts folios
from higher zones as skipped and, once max_nr_skipped hits
SWAP_CLUSTER_MAX_SKIPPED, force-isolates the remaining ineligible folios
to keep the loop from spinning on the skipped ones.  Those folios are
reclaimed even though they can never satisfy the current allocation, so
nr_reclaimed is inflated into a false progress that keeps resetting
no_progress_loops in should_reclaim_retry() and delays the OOM.

Stop scanning once max_nr_skipped is reached instead of force-isolating
the ineligible folios.  The skipped folios are already accounted in
total_scan, so shrink_lruvec() can charge the overshoot against its scan
budget (see the previous commit) and will not rescan them.

Fixes: 1c7b17cf0594 ("mm/vmscan: fix hard LOCKUP in function isolate_lru_folios")
Signed-off-by: Wupeng Ma <mawupeng1@huawei.com>
---
 mm/vmscan.c | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 147e74f9732d5..ac3237a58cb29 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1704,12 +1704,20 @@ static unsigned long isolate_lru_folios(unsigned long nr_to_scan,
 		nr_pages = folio_nr_pages(folio);
 		total_scan += nr_pages;
 
-		/* Using max_nr_skipped to prevent hard LOCKUP*/
-		if (max_nr_skipped < SWAP_CLUSTER_MAX_SKIPPED &&
-		    (folio_zonenum(folio) > sc->reclaim_idx)) {
+		/*
+		 * Using max_nr_skipped to prevent hard LOCKUP.
+		 * Once the cap is hit, stop rather than force-isolating:
+		 * reclaiming ineligible folios only inflates nr_reclaimed
+		 * into a false progress.
+		 */
+		if (folio_zonenum(folio) > sc->reclaim_idx) {
 			nr_skipped[folio_zonenum(folio)] += nr_pages;
-			move_to = &folios_skipped;
 			max_nr_skipped++;
+			if (max_nr_skipped >= SWAP_CLUSTER_MAX_SKIPPED) {
+				list_move(&folio->lru, &folios_skipped);
+				break;
+			}
+			move_to = &folios_skipped;
 			goto move;
 		}
 
-- 
2.43.0

Re: [PATCH 0/2] mm: vmscan: fix scan overshoot and ineligible folio scanning

[Andrew Morton]

On Tue, 11 Aug 2026 15:08:47 +0800 Wupeng Ma <mawupeng1@huawei.com> wrote:

> shrink_lruvec() drives reclaim in SWAP_CLUSTER_MAX (32) chunks, but
> isolate_lru_folios() may scan far more than that per call on a single
> LRU.  The excess is never charged back, so shrink_lruvec() keeps
> rescanning the same folios round after round.  When reclaim targets a
> lower zone, the same scanner also keeps walking zone-ineligible folios
> that can never satisfy the allocation, inflating nr_reclaimed into a
> false progress that delays the OOM.
> 
> This series fixes both:
> 
>   [1/2] Charge the isolate overshoot against the scan quota so the
>         next round skips already-scanned folios.
>   [2/2] Stop scanning once too many zone-ineligible folios have been
>         skipped, instead of force-isolating them.

This all sounds fairly bad.  Is there some report?  Real-world test
results?  Laboratory test results?  Something to help us understand the
impact of the issues and the situations in which they occur.

Thanks.

Re: [PATCH 0/2] mm: vmscan: fix scan overshoot and ineligible folio scanning

[mawupeng]

On 周三 2026-8-12 09:42, Andrew Morton wrote:
> On Tue, 11 Aug 2026 15:08:47 +0800 Wupeng Ma <mawupeng1@huawei.com> wrote:
> 
>> shrink_lruvec() drives reclaim in SWAP_CLUSTER_MAX (32) chunks, but
>> isolate_lru_folios() may scan far more than that per call on a single
>> LRU.  The excess is never charged back, so shrink_lruvec() keeps
>> rescanning the same folios round after round.  When reclaim targets a
>> lower zone, the same scanner also keeps walking zone-ineligible folios
>> that can never satisfy the allocation, inflating nr_reclaimed into a
>> false progress that delays the OOM.
>>
>> This series fixes both:
>>
>>   [1/2] Charge the isolate overshoot against the scan quota so the
>>         next round skips already-scanned folios.
>>   [2/2] Stop scanning once too many zone-ineligible folios have been
>>         skipped, instead of force-isolating them.
> 
> This all sounds fairly bad.  Is there some report?  Real-world test
> results?  Laboratory test results?  Something to help us understand the
> impact of the issues and the situations in which they occur.
> 

Sorry — this background belongs in the cover letter and I left it
out.  Adding it here.

## Situation

We observed slow, unexpected OOM behavior during extreme stress testing,
and while digging into the reclaim code during that analysis we spotted
these latent risks in isolate_lru_folios() — the overshoot never
being charged back, and the force-isolate path on lower-zone reclaim.
The concerns below are the ones surfaced from reading the code, then
confirmed by constructing the situation deliberately.

The problem only appears when reclaim targets a lower zone while the
LRU holds folios from a higher zone:

  - reclaim_idx points at DMA32/DMA (the triggering allocation asked
    for a lower zone, e.g. __GFP_DMA32), and
  - the LRU holds folios from a higher zone (Normal/Movable).

Normal userspace allocations go to the highest zone, so reclaim_idx
never points below it and the zone-skip branch is never taken.  It
needs a real lower-zone allocator to drain that zone below watermark;
that is also why it went unnoticed upstream — the 1c7b17cf hard-lockup
fix that introduced the force-isolate path was found only on a ~1 TB
box running DMA32 module allocations.

## Impact

Reproduced on x86 QEMU, 7.2-rc6, with a kernel module doing
__GFP_DMA32 allocations to drain DMA32 below watermark (LRU folios
sit in Movable):

  - A single isolate_lru_folios() call scanned 32794 pages and took
    25 (32769 skipped): 99.9% wasted on ineligible folios.
  - Across one run, isolate was called 339 times, 140-165 of which
    isolated nothing (taken=0, pure empty scans).
  - shrink_lruvec() charges only the 32-page quota per round and
    never refunds the overshoot, so the same skipped folios are
    rescanned round after round.  vmstat on a memcg OOM path:
    Δpgscan_direct / Δpgsteal_direct = 2836624 / 112719 = 25.2x
    (isolate -> shrink_folio_list returns the folio -> isolate again).

Once max_nr_skipped hits SWAP_CLUSTER_MAX_SKIPPED, the current code
force-isolates the remaining ineligible folios.  On the inactive LRU
they reach shrink_folio_list() and get reclaimed though they can
never satisfy the allocation, inflating nr_reclaimed and resetting
no_progress_loops in should_reclaim_retry(), delaying the OOM.

## A/B results (same .config, md5-identical)

| metric                  | baseline   | patched | note |
|-------------------------|------------|---------|------|
| empty scans (taken=0)   | 140-165    | 0       | stable across runs |
| isolate calls           | 339        | 7       | 48x fewer |
| total pages scanned     | 343711     | 3140    | 109x fewer |
| single-call max scan    | 32794      | 3104    | |

Empty-scan 0 is the stable evidence (holds every run).  The
Δpgscan/Δpgsteal ratio is volatile (baseline 56-26675x, patched
65-1324x, ranges overlap) and is not relied on alone.

## Caveats and reproduction

  - Triggering needs a lower-zone-pressured box.  To confirm the code
    analysis, the situation was constructed on a small x86 QEMU VM
    (1500M, CONFIG_LRU_GEN=n) with kernel cmdline
    `movable_zone=DMA32 kernelcore=256M` (DMA32 small, Normal empty,
    Movable large), then a kernel module doing
    `alloc_page(GFP_DMA32)` drains DMA32 below watermark.  LRU folios
    sit in Movable and are zone-skipped while reclaiming for DMA32.
    Observed via the `mm_vmscan_lru_isolate` tracepoint and
    /proc/vmstat (pgscan_direct, pgsteal_direct).

> Thanks.

Re: [PATCH 0/2] mm: vmscan: fix scan overshoot and ineligible folio scanning

[mawupeng]

Hi, maintainers
  Kindly ping.

On 周三 2026-8-12 10:29, mawupeng wrote:
> 
> 
> On 周三 2026-8-12 09:42, Andrew Morton wrote:
>> On Tue, 11 Aug 2026 15:08:47 +0800 Wupeng Ma <mawupeng1@huawei.com> wrote:
>>
>>> shrink_lruvec() drives reclaim in SWAP_CLUSTER_MAX (32) chunks, but
>>> isolate_lru_folios() may scan far more than that per call on a single
>>> LRU.  The excess is never charged back, so shrink_lruvec() keeps
>>> rescanning the same folios round after round.  When reclaim targets a
>>> lower zone, the same scanner also keeps walking zone-ineligible folios
>>> that can never satisfy the allocation, inflating nr_reclaimed into a
>>> false progress that delays the OOM.
>>>
>>> This series fixes both:
>>>
>>>   [1/2] Charge the isolate overshoot against the scan quota so the
>>>         next round skips already-scanned folios.
>>>   [2/2] Stop scanning once too many zone-ineligible folios have been
>>>         skipped, instead of force-isolating them.
>>
>> This all sounds fairly bad.  Is there some report?  Real-world test
>> results?  Laboratory test results?  Something to help us understand the
>> impact of the issues and the situations in which they occur.
>>
> 
> Sorry — this background belongs in the cover letter and I left it
> out.  Adding it here.
> 
> ## Situation
> 
> We observed slow, unexpected OOM behavior during extreme stress testing,
> and while digging into the reclaim code during that analysis we spotted
> these latent risks in isolate_lru_folios() — the overshoot never
> being charged back, and the force-isolate path on lower-zone reclaim.
> The concerns below are the ones surfaced from reading the code, then
> confirmed by constructing the situation deliberately.
> 
> The problem only appears when reclaim targets a lower zone while the
> LRU holds folios from a higher zone:
> 
>   - reclaim_idx points at DMA32/DMA (the triggering allocation asked
>     for a lower zone, e.g. __GFP_DMA32), and
>   - the LRU holds folios from a higher zone (Normal/Movable).
> 
> Normal userspace allocations go to the highest zone, so reclaim_idx
> never points below it and the zone-skip branch is never taken.  It
> needs a real lower-zone allocator to drain that zone below watermark;
> that is also why it went unnoticed upstream — the 1c7b17cf hard-lockup
> fix that introduced the force-isolate path was found only on a ~1 TB
> box running DMA32 module allocations.
> 
> ## Impact
> 
> Reproduced on x86 QEMU, 7.2-rc6, with a kernel module doing
> __GFP_DMA32 allocations to drain DMA32 below watermark (LRU folios
> sit in Movable):
> 
>   - A single isolate_lru_folios() call scanned 32794 pages and took
>     25 (32769 skipped): 99.9% wasted on ineligible folios.
>   - Across one run, isolate was called 339 times, 140-165 of which
>     isolated nothing (taken=0, pure empty scans).
>   - shrink_lruvec() charges only the 32-page quota per round and
>     never refunds the overshoot, so the same skipped folios are
>     rescanned round after round.  vmstat on a memcg OOM path:
>     Δpgscan_direct / Δpgsteal_direct = 2836624 / 112719 = 25.2x
>     (isolate -> shrink_folio_list returns the folio -> isolate again).
> 
> Once max_nr_skipped hits SWAP_CLUSTER_MAX_SKIPPED, the current code
> force-isolates the remaining ineligible folios.  On the inactive LRU
> they reach shrink_folio_list() and get reclaimed though they can
> never satisfy the allocation, inflating nr_reclaimed and resetting
> no_progress_loops in should_reclaim_retry(), delaying the OOM.
> 
> ## A/B results (same .config, md5-identical)
> 
> | metric                  | baseline   | patched | note |
> |-------------------------|------------|---------|------|
> | empty scans (taken=0)   | 140-165    | 0       | stable across runs |
> | isolate calls           | 339        | 7       | 48x fewer |
> | total pages scanned     | 343711     | 3140    | 109x fewer |
> | single-call max scan    | 32794      | 3104    | |
> 
> Empty-scan 0 is the stable evidence (holds every run).  The
> Δpgscan/Δpgsteal ratio is volatile (baseline 56-26675x, patched
> 65-1324x, ranges overlap) and is not relied on alone.
> 
> ## Caveats and reproduction
> 
>   - Triggering needs a lower-zone-pressured box.  To confirm the code
>     analysis, the situation was constructed on a small x86 QEMU VM
>     (1500M, CONFIG_LRU_GEN=n) with kernel cmdline
>     `movable_zone=DMA32 kernelcore=256M` (DMA32 small, Normal empty,
>     Movable large), then a kernel module doing
>     `alloc_page(GFP_DMA32)` drains DMA32 below watermark.  LRU folios
>     sit in Movable and are zone-skipped while reclaiming for DMA32.
>     Observed via the `mm_vmscan_lru_isolate` tracepoint and
>     /proc/vmstat (pgscan_direct, pgsteal_direct).
> 
>> Thanks.
> 

Re: [PATCH 0/2] mm: vmscan: fix scan overshoot and ineligible folio scanning

[Andrew Morton]

On Tue, 25 Aug 2026 08:59:54 +0800 mawupeng <mawupeng1@huawei.com> wrote:

> Hi, maintainers
>   Kindly ping.

It's been quite a while.  It would be helpful to refresh/retest/resend,
please.

While doing this, please update the changelogging to help reviewers
understand the end-user impact of the issue.

Please also give some though to whether we should backport these fixes
into earlier kernels, with a cc:stable.  Given the unusual
circumstances which are required to hit this, I'm thinking "no", but
feel free to disagree!