Re: [PATCH mm-new v9] mm: vmscan: retry folios written back while isolated for traditional LRU

From: Barry Song

Date: Wed Sep 16 2026 - 17:58:58 EST


On Thu, Sep 17, 2026 at 5:25 AM Barry Song <baohua@xxxxxxxxxx> wrote:
[...]
> I don't like the way you describe the problem as "wasted" swap.
>
> The real problem is that those folios skipped
> `folio_rotate_reclaimable()`, so they were added back to the head
> instead of the tail, where rotation could have moved them to the tail.
> This resulted in a cold/hot inversion.
>
> The swap entries they are using now will eventually be released when
> we scan those folios again and reach the head of the list, so this is
> not actually wasted swap space. You are probably right, on the other
> hand, that if those head folios hold swap entries and the swap is
> full, this could prevent the reclamation of folios at the tail, making
> it even harder for us to reach the head.
>
> >
> > This issue should be fixed in the same way as mglru. Therefore, the common
> > logic was extracted to the 'find_folios_written_back' function firstly,
> > which is then reused in the 'shrink_inactive_list' function. Finally,
> > retry reclaiming those folios that may have missed the rotation for
> > traditional LRU.
>
> I wouldn't necessarily call it a fix, as keeping the swap cache for
> those folios can sometimes help with future hits. For example, we may
> hit those folios again before they are reclaimed. So it's a
> double-edged sword.
>
> That said, the cold/hot inversion is a real problem that we should
> fix. Ideally, we should find a way to restore the missed
> `folio_rotate_reclaimable()` behavior, conceptually something like:

BTW, maybe we should have another patch to fix `MADV_PAGEOUT`.

Thinking about madv_pageout, we are supposed to reclaim those
folios. But because the swap device is fast, they miss
`folio_rotate_reclaimable()`. As a result, we not only fail to reclaim
the folios, but actually promote the very folios that we are supposed
to reclaim. This seems pretty problematic.

This is probably a common problem shared by both CLRU and MGLRU.

Best Regards
Barry