On 26.08.24 10:50, zhaoyang.huang wrote:
From: Zhaoyang Huang <zhaoyang.huang@xxxxxxxxxx>
Since clean target folio with private data will be given up finally in
__remove_mapping as it has extra refcnt, it is better to skip it during
isolation to save the slot for more qualified folio. Current one could
be the candidate for next round of scanning after the private data gone.
Signed-off-by: Zhaoyang Huang <zhaoyang.huang@xxxxxxxxxx>
---
mm/vmscan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index cfa839284b92..755bf3a387f3 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1685,6 +1685,8 @@ static unsigned long isolate_lru_folios(unsigned long nr_to_scan,
*/
scan += nr_pages;
+ if (folio_test_private(folio) && !folio_test_dirty(folio))
+ goto move;
if (!folio_test_lru(folio))
goto move;
if (!sc->may_unmap && folio_mapped(folio))
An earlier filemap_release_folio() would have failed if the private data
(buffers) cannot get freed, and we went into the activate_locked path.
if (folio_needs_release(folio)) {
if (!filemap_release_folio(folio, sc->gfp_mask)
goto activate_locked;
...
if (folio_test_anon(folio) && !folio_test_swapbacked(folio)) {
...
} else if (!mapping || !__remove_mapping(mapping, folio, true,
}
At least on the shrink_folio_list() path, I'm not sure the code you are
adding could even trigger. We should not reach __remove_mapping() with
folio_test_private().
--
Cheers,
David / dhildenb
