Re: [PATCH 4/8] mm/swap: Use PG_dropbehind instead of PG_reclaim
From: Yosry Ahmed <hidden>
Date: 2025-01-13 16:17:58
Also in:
dri-devel, intel-gfx, linux-fsdevel, linux-mm, lkml
On Mon, Jan 13, 2025 at 1:35 AM Kirill A. Shutemov [off-list ref] wrote:
quoted hunk ↗ jump to hunk
The recently introduced PG_dropbehind allows for freeing folios immediately after writeback. Unlike PG_reclaim, it does not need vmscan to be involved to get the folio freed. Instead of using folio_set_reclaim(), use folio_set_dropbehind() in lru_deactivate_file(). Signed-off-by: Kirill A. Shutemov <redacted> --- mm/swap.c | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-)diff --git a/mm/swap.c b/mm/swap.c index fc8281ef4241..4eb33b4804a8 100644 --- a/mm/swap.c +++ b/mm/swap.c@@ -562,14 +562,8 @@ static void lru_deactivate_file(struct lruvec *lruvec, struct folio *folio) folio_clear_referenced(folio); if (folio_test_writeback(folio) || folio_test_dirty(folio)) { - /* - * Setting the reclaim flag could race with - * folio_end_writeback() and confuse readahead. But the - * race window is _really_ small and it's not a critical - * problem. - */ lruvec_add_folio(lruvec, folio); - folio_set_reclaim(folio); + folio_set_dropbehind(folio); } else { /* * The folio's writeback ended while it was in the batch.
Now there's a difference in behavior here depending on whether or not the folio is under writeback (or will be written back soon). If it is, we set PG_dropbehind to get it freed right after, but if writeback has already ended we put it on the tail of the LRU to be freed later. It's a bit counterintuitive to me that folios with pending writeback get freed faster than folios that completed their writeback already. Am I missing something?