Re: [PATCH 1/1] mm/vmscan: avoid split PMD-mapped THP during shrink_folio_list()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 20.04.24 17:04, Lance Yang wrote:
On Sat, Apr 20, 2024 at 12:59 PM Lance Yang <ioworker0@xxxxxxxxx> wrote:

Hey Matthew,

Thanks for taking time to review!

On Wed, Apr 17, 2024 at 11:09 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:

On Wed, Apr 17, 2024 at 10:11:11PM +0800, Lance Yang wrote:
When the user no longer requires the pages, they would use madvise(madv_free)
to mark the pages as lazy free. IMO, they would not typically rewrite to the
given range.

At present, a PMD-mapped THP marked as lazyfree during shrink_folio_list()
is unconditionally split, which may be unnecessary. If the THP is exclusively
mapped and clean, and the PMD associated with it is also clean, then we can
attempt to remove the PMD mapping from it. This change will improve the
efficiency of memory reclamation in this case.

On an Intel i5 CPU, reclaiming 1GiB of PMD-mapped THPs using
mem_cgroup_force_empty() results in the following runtimes in seconds
(shorter is better):

--------------------------------------------
|     Old       |      New       |  Change  |
--------------------------------------------
|   0.683426    |    0.049197    |  -92.80% |
--------------------------------------------

Signed-off-by: Lance Yang <ioworker0@xxxxxxxxx>
---
  include/linux/huge_mm.h |  1 +
  include/linux/rmap.h    |  1 +
  mm/huge_memory.c        |  2 +-
  mm/rmap.c               | 81 +++++++++++++++++++++++++++++++++++++++++
  mm/vmscan.c             |  7 ++++
  5 files changed, 91 insertions(+), 1 deletion(-)

I'm confused why we need all this extra code.  If we remove a folio

Thanks for pointing that out!

I've added a lot of extra code to rmap.c, and we don't need it
for file pages - sorry. I'll reconsider where to place this code.

from the pagecache, we can just call truncate_inode_folio() and
unmap_mapping_folio() takes care of all the necessary unmappings.
Why can't you call unmap_mapping_folio() here?

Thanks for your suggestion.

But this change only avoids the splitting of *anon* large folios
(PMD-mapped THPs) that are marked as lazyfree during
shrink_folio_list().

IIUC, in some cases, we cannot unmap the THP marked as lazyfree
here, such as when it's not exclusively mapped, dirty, pinned, etc.

I’d like to make a correction.

IMO, we can unmap the THP that is not exclusively mapped, but
ensuring folio_ref_count() equals folio_mapcount() +1.

You must follow the exact same logic as in try_to_unmap_one() I guess.

That is, unmap the page, syncing against concurrent GUP-fast. Then, check mapcount vs. refcount. If there are unexpected references, remap the page (set_pte_at).

--
Cheers,

David / dhildenb





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux