linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Lance Yang <ioworker0@gmail.com>
To: Matthew Wilcox <willy@infradead.org>
Cc: akpm@linux-foundation.org, maskray@google.com, ziy@nvidia.com,
	 ryan.roberts@arm.com, david@redhat.com, 21cnbao@gmail.com,
	mhocko@suse.com,  fengwei.yin@intel.com, zokeefe@google.com,
	shy828301@gmail.com,  xiehuan09@gmail.com,
	wangkefeng.wang@huawei.com, songmuchun@bytedance.com,
	 peterx@redhat.com, minchan@kernel.org, linux-mm@kvack.org,
	 linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] mm/vmscan: avoid split PMD-mapped THP during shrink_folio_list()
Date: Sat, 20 Apr 2024 23:04:56 +0800	[thread overview]
Message-ID: <CAK1f24=0S8qFFNhf5h=wbbAHvYt-n563MOu=bJheLcrfcPAE_Q@mail.gmail.com> (raw)
In-Reply-To: <CAK1f24=Mrk7TFnDd=ouCrHaDH9K3VGCUAJbLH9cbn0pGncP+Hw@mail.gmail.com>

On Sat, Apr 20, 2024 at 12:59 PM Lance Yang <ioworker0@gmail.com> wrote:
>
> Hey Matthew,
>
> Thanks for taking time to review!
>
> On Wed, Apr 17, 2024 at 11:09 PM Matthew Wilcox <willy@infradead.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@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
>
> 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.

Thanks,
Lance

> 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


  reply	other threads:[~2024-04-20 15:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-17 14:11 Lance Yang
2024-04-17 15:02 ` David Hildenbrand
2024-04-18  6:40   ` Lance Yang
2024-04-17 15:08 ` Matthew Wilcox
2024-04-20  4:59   ` Lance Yang
2024-04-20 15:04     ` Lance Yang [this message]
2024-04-20 16:31       ` David Hildenbrand

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='CAK1f24=0S8qFFNhf5h=wbbAHvYt-n563MOu=bJheLcrfcPAE_Q@mail.gmail.com' \
    --to=ioworker0@gmail.com \
    --cc=21cnbao@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@redhat.com \
    --cc=fengwei.yin@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=maskray@google.com \
    --cc=mhocko@suse.com \
    --cc=minchan@kernel.org \
    --cc=peterx@redhat.com \
    --cc=ryan.roberts@arm.com \
    --cc=shy828301@gmail.com \
    --cc=songmuchun@bytedance.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=willy@infradead.org \
    --cc=xiehuan09@gmail.com \
    --cc=ziy@nvidia.com \
    --cc=zokeefe@google.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