Re: [PATCH v6 00/14] mm/mglru: improve reclaim loop and dirty folio handling

[Kairui Song]

On Sun, Apr 26, 2026 at 4:35 PM Barry Song <baohua@xxxxxxxxxx> wrote:
>
>
> Either approach is fine—use whichever works better for organizing v7.
> My boss would definitely be happier with the latter, as it would better
> support and encourage more active engagement in upstream development.
> It’s rare these days to find a boss like this who is open-minded and
> insightful about upstream contributions, especially with everyone
> moving toward AI. :-)

Will attach your patch as a standalone one right next to patch 5 then,
the effect is not easy to hit I think, and shouldn't break any bisect.

I just ran a set of tests, just in case it has any unexpected
behavior, it seems identical to what we have in V5 with all my test cases:

FIO:
Before: 8968.76 MB/s
V5 (this series): 9005.89 MB/s
V6 (with your fix and nitpick from sashiko): 8995.63 MB/s

Build kernel:
Before: 2873.52
V5 (this series): 2816.44s
V6 (with your fix and nitpick from sashiko): 2811.88s

MySQL:
Before: 17303.414444 tps
V5 (this series): 17310.528750
V6 (with your fix and nitpick from sashiko): 17291.500000 tps

MongoDB with YCSB workoad b:
Before: 59227.33 ops/s
V6: 79928.53 ops/sec

Still matches the V5 cover letter and everything looks great, also
seems alright on my android phone. Will send V6 later.

>
> >
> > One related thought for a follow-up: scanned == 0 from scan_folios()
> > is essentially driven by get_nr_gens(lruvec, type) == MIN_NR_GENS. So
> > when the type get_type_to_scan() picked is the one that's
> > gen-exhausted, maybe the right response is also to age that type
> > rather than fall back. Right now should_run_aging() only looks at the
> > combined evictable_min_seq, so the ctrl_err preferred type can
> > silently stay starved while we evict from the other one, that could be
> > an old issue we can fix later.
>
> Yep, I’ve been thinking about the same thing for quite a
> few days. This might also help address swappiness. On the
> other hand, it could lead to more aging, but it seems like
> a necessary trade-off if we want a simple solution that
> doesn’t require separate max_seq for file and anon to fix
> swappiness for mglru.
>
> I’m also trying another approach. For example, if the
> number of folios in the old generation is too low relative
> to swappiness, should_run_aging() could return true—similar
> to Yu’s earliest patch as below, but with a swappiness bias.
>
> + /*
> + * It's also ideal to spread pages out evenly, i.e., 1/(MIN_NR_GENS+1)
> + * of the total number of pages for each generation. A reasonable range
> + * for this average portion is [1/MIN_NR_GENS, 1/(MIN_NR_GENS+2)]. The
> + * aging cares about the upper bound of hot pages, while the eviction
> + * cares about the lower bound of cold pages.
> + */
> + if (young * MIN_NR_GENS > total)
> +        return true;
> + if (old * (MIN_NR_GENS + 2) < total)
> +        return true;
>
> Hopefully, the above can resolve the problem before we have to
> resort to separate max_seq, which would break the shared time
> axis between file and anon.
>
> Maybe I will send an RFC before LSF/MM/BPF if we have enough
> time.

Good idea, that can also be discussed there.