[RFC,v3,0/2] mm: vmscan: retry folios written back while isolated

Message

Chen Ridong Dec. 4, 2024, 4:01 a.m. UTC

From: Chen Ridong <[e-mail]>

The page reclaim isolates a batch of folios from the tail of one of the
LRU lists and works on those folios one by one.  For a suitable
swap-backed folio, if the swap device is async, it queues that folio for
writeback.  After the page reclaim finishes an entire batch, it puts back
the folios it queued for writeback to the head of the original LRU list.

In the meantime, the page writeback flushes the queued folios also by
batches.  Its batching logic is independent from that of the page reclaim.
For each of the folios it writes back, the page writeback calls
folio_rotate_reclaimable() which tries to rotate a folio to the tail.

folio_rotate_reclaimable() only works for a folio after the page reclaim
has put it back.  If an async swap device is fast enough, the page
writeback can finish with that folio while the page reclaim is still
working on the rest of the batch containing it.  In this case, that folio
will remain at the head and the page reclaim will not retry it before
reaching there.

This issue has been fixed for multi-gen LRU with commit 359a5e1416ca ("mm:
multi-gen LRU: retry folios written back while isolated"). Fix this issue
in the same way for active/inactive lru.

---
v3:
 - fix this issue in the same with way as multi-gen LRU.

v2:
 - detect folios whose writeback has done and move them to the tail
    of lru. suggested by Barry Song
[2] https://lore.kernel.org/linux-kernel/[e-mail]/

v1:
[1] https://lore.kernel.org/linux-kernel/[e-mail]/

Chen Ridong (2):
  mm: vmascan: add find_folios_written_back() helper
  mm: vmscan: retry folios written back while isolated

 mm/vmscan.c | 108 ++++++++++++++++++++++++++++++++++++----------------
 1 file changed, 76 insertions(+), 32 deletions(-)