lkml.org 
[lkml]   [2024]   [Apr]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/1] mm/vmscan: avoid split PMD-mapped THP during shrink_folio_list()
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@gmail.com>
> ---
> 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
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?

\
 
 \ /
  Last update: 2024-04-17 17:09    [W:2.026 / U:1.720 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site