[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250106031711.82855-1-21cnbao@gmail.com>
Date: Mon, 6 Jan 2025 16:17:08 +1300
From: Barry Song <21cnbao@...il.com>
To: akpm@...ux-foundation.org,
linux-mm@...ck.org
Cc: linux-arm-kernel@...ts.infradead.org,
x86@...nel.org,
linux-kernel@...r.kernel.org,
ioworker0@...il.com,
david@...hat.com,
ryan.roberts@....com,
zhengtangquan@...o.com,
ying.huang@...el.com,
kasong@...cent.com,
chrisl@...nel.org,
baolin.wang@...ux.alibaba.com,
Barry Song <v-songbaohua@...o.com>
Subject: [PATCH 0/3] mm: batched unmap lazyfree large folios during reclamation
From: Barry Song <v-songbaohua@...o.com>
Commit 735ecdfaf4e80 ("mm/vmscan: avoid splitting lazyfree THP during
shrink_folio_list()") prevents the splitting of MADV_FREE'd THP in madvise.c.
However, those folios are still added to the deferred_split list in
try_to_unmap_one() because we are unmapping PTEs and removing rmap entries
one by one. This approach is not only slow but also increases the risk of a
race condition where lazyfree folios are incorrectly set back to swapbacked,
as a speculative folio_get may occur in the shrinker's callback.
This patchset addresses the issue by only marking truly dirty folios as
swapbacked as suggested by David and shifting to batched unmapping of the
entire folio in try_to_unmap_one(). As a result, we've observed
deferred_split dropping to zero and significant performance improvements
in memory reclamation.
Barry Song (3):
mm: set folio swapbacked iff folios are dirty in try_to_unmap_one
mm: Support tlbbatch flush for a range of PTEs
mm: Support batched unmap for lazyfree large folios during reclamation
arch/arm64/include/asm/tlbflush.h | 26 ++++----
arch/arm64/mm/contpte.c | 2 +-
arch/x86/include/asm/tlbflush.h | 3 +-
mm/rmap.c | 103 ++++++++++++++++++++----------
4 files changed, 85 insertions(+), 49 deletions(-)
--
2.39.3 (Apple Git-146)
Powered by blists - more mailing lists