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

[Andrew Morton <akpm@linux-foundation.org>]

On Tue,  1 Sep 2026 16:47:04 +0800 john <love_goo@163.com> wrote:

> From: Wupeng Ma <mawupeng1@huawei.com>
> 
> Rebase to the latest v7.3-rc-1.
> 
> These problems only surface when reclaim targets a lower zone
> while the LRU holds folios from a higher zone.  Normal userspace
> allocations go to the highest zone.  The zone-skip branch stays
> dead under typical loads.  Lower-zone-pressured configs (DMA32
> module allocations, memory-constrained devices) hit the issues.
> They inflate scan cost and delay the OOM.
> 
> 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.
> 
> Background
> ==========
> 
> We observed slow, unexpected OOM behavior during extreme stress testing,

OK.  But why should we care?  Don't do extreme stress testing on your
revenue-generating customer-facing computers!

IOW, as long as the stress tests don't crash the kernel or lock up the
box, we can spend our time thinking about kernel behavior which really
matters.

Now, if these changes can be shown to translate into improvement in
real-world workloads then they're useful.

Am I wrong?