linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Barry Song <21cnbao@gmail.com>
To: akpm@linux-foundation.org, linux-mm@kvack.org
Cc: linux-arm-kernel@lists.infradead.org, x86@kernel.org,
	linux-kernel@vger.kernel.org, ioworker0@gmail.com,
	david@redhat.com, ryan.roberts@arm.com, zhengtangquan@oppo.com,
	ying.huang@intel.com, kasong@tencent.com, chrisl@kernel.org,
	baolin.wang@linux.alibaba.com, Barry Song <v-songbaohua@oppo.com>
Subject: [PATCH 0/3] mm: batched unmap lazyfree large folios during reclamation
Date: Mon,  6 Jan 2025 16:17:08 +1300	[thread overview]
Message-ID: <20250106031711.82855-1-21cnbao@gmail.com> (raw)

From: Barry Song <v-songbaohua@oppo.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)



             reply	other threads:[~2025-01-06  3:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-01-06  3:17 Barry Song [this message]
2025-01-06  3:17 ` [PATCH 1/3] mm: set folio swapbacked iff folios are dirty in try_to_unmap_one Barry Song
2025-01-06  6:40   ` Baolin Wang
2025-01-06  9:03     ` Barry Song
2025-01-06  9:34       ` Baolin Wang
2025-01-06 14:39         ` Lance Yang
2025-01-06 20:52           ` Barry Song
2025-01-06 20:56             ` Barry Song
2025-01-07  1:33           ` Lance Yang
2025-01-06  3:17 ` [PATCH 2/3] mm: Support tlbbatch flush for a range of PTEs Barry Song
2025-01-06  8:22   ` kernel test robot
2025-01-13  0:55     ` Barry Song
2025-01-13 13:13       ` Oliver Sang
2025-01-06 10:07   ` kernel test robot
2025-01-13  0:56     ` Barry Song
2025-01-13  7:30       ` Oliver Sang
2025-01-06  3:17 ` [PATCH 3/3] mm: Support batched unmap for lazyfree large folios during reclamation Barry Song
2025-01-06 17:28 ` [PATCH 0/3] mm: batched unmap " Lorenzo Stoakes
2025-01-06 19:15   ` Barry Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250106031711.82855-1-21cnbao@gmail.com \
    --to=21cnbao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=chrisl@kernel.org \
    --cc=david@redhat.com \
    --cc=ioworker0@gmail.com \
    --cc=kasong@tencent.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ryan.roberts@arm.com \
    --cc=v-songbaohua@oppo.com \
    --cc=x86@kernel.org \
    --cc=ying.huang@intel.com \
    --cc=zhengtangquan@oppo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox