linux-kernel - Re: [PATCH 1/1] mm/vmscan: avoid split PMD-mapped THP during shrink_folio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Sat, 20 Apr 2024 12:59:07 +0800
From: Lance Yang <ioworker0@...il.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: akpm@...ux-foundation.org, maskray@...gle.com, ziy@...dia.com, 
	ryan.roberts@....com, david@...hat.com, 21cnbao@...il.com, mhocko@...e.com, 
	fengwei.yin@...el.com, zokeefe@...gle.com, shy828301@...il.com, 
	xiehuan09@...il.com, wangkefeng.wang@...wei.com, songmuchun@...edance.com, 
	peterx@...hat.com, minchan@...nel.org, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] mm/vmscan: avoid split PMD-mapped THP during shrink_folio_list()

Hey Matthew,

Thanks for taking time to review!

On Wed, Apr 17, 2024 at 11:09 PM Matthew Wilcox <willy@...radead.org> 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@...il.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

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.
In such situations, we still need to return to try_to_unmap_one(), and
then call split_huge_pmd_address() to split it.

Thanks again for the review.
Lance