Re: [PATCH 0/3] mm/mglru: clean up isolate_folios and scan_folios for readability and clarity

[Kairui Song]

On Thu, Aug 27, 2026 at 2:21 PM Baolin Wang
<baolin.wang@xxxxxxxxxxxxxxxxx> wrote:
>
> With the above changes, I can also reproduce the slight regression with
> NVMe swap (set swappiness = 100) mentioned by Kairui (but the zram case
> still looks good):
>
> Before:
> sys: 757
> refault_anon 5554715
> refault_file 3867998
>
> After:
> sys: 765
> refault_anon 5791349
> refault_file 3939552
>

...

>
> Thanks Kairui for your data and anylysis.
>
> I mostly agree. But on whether we should fallback more, I still prefer
> Barry's idea. The current patch might be a bit too aggressive, cause it
> only fallback to another type when the oldest generation is fully
> exhausted. I've always felt that falling back too easily doesn't really
> respect the PID's choice.
>
> Of course, there's also the concern you raised about the limitation in
> try_to_inc_min_seq() when updating the min_seq. I think we can address
> that together later, so that we respect the PID's choice (i.e., try the
> reclaimed type as much as possible) without ending up with a tailing
> draining generation that blocks aging. That may not be simple, though.

Actually in the long term I think we should get away from the PID
rather than respect it more for eviction choice :), and use a actual
calculation that respects swappiness and IO cost (we can still use
the data collected by it though).

There is another series form Barry (and the clean up here is extracted from it):
https://lore.kernel.org/linux-mm/20260812121658.69965-1-baohua@xxxxxxxxxx/

To achieve reasonable swappiness following the PID and aging
protection idea, we will inevitably increase overhead, and PID is
really bad at protecting the cache anyway.

PID controllers generally correct long-term linear statistic well, but
they aren't well-suited to reacting to abrupt workload changes. While
MM workloads are full of such bursts and phase changes. What's worse
the design aggregates folios into tiers based on access, and the
limited high tier means folios staying in the same high tier can have
dramatically different access behaviors.

I think PID still makes sense as a long-term reference: it can correct
cross-generation behavior over time, but relying on it as the primary
mechanism for for single type eviction or protection is problematic.
In my view, this is also one of the major limitations that has made
MGLRU difficult to generalize across a wide range of workloads.

See: https://lore.kernel.org/linux-mm/20260804-mglru-fg-v1-0-4d8dad39dad6@xxxxxxxxxxx/,
by softening PID protection (still used, just with a much lower
factor) and using FG protection, zipf and real workloads gets a much
higher hit rate (much higher than 10%, and dramatically better in many
cases, the basic 10% gain is end-to-end gain diluted by the overall
cost).

So in the long term I think: For promotion, we will use FG; for
eviction (the issue being patched here and in that Barry's other
patch), we will respect swappiness & IO cost based scan budget
calculation. Currently, the IO cost is just the refault count, which
seems fine, this is similar to classical LRU, but ignores scan cost
because MGLRU's scan is special, full of lazy-promoted folios that
already offset the scan budget well. PID can stay to catch long term
characteristics, at a weaker factor.

(BTW I know that PID have a way to be more adaptive to bursts;
however, that's really hard to tune for MM, and doesn't fix the long
time cold folio stay in same high tier issue).

Maybe I'll just post a series soon for the eviction part.

>
> Anyway, personally I'd prefer to keep the original code until more
> impact investigation is done.
>
> Just my 2 cents.

No problem, I'm OK with this change for now.