[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK1f24nN+DgU7rz0zV4DEwJwWe_CZcpR7GROMxWfWbo+cnr71g@mail.gmail.com>
Date: Sun, 21 Apr 2024 10:00:31 +0800
From: Lance Yang <ioworker0@...il.com>
To: David Hildenbrand <david@...hat.com>
Cc: Matthew Wilcox <willy@...radead.org>, akpm@...ux-foundation.org, maskray@...gle.com,
ziy@...dia.com, ryan.roberts@....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()
On Sun, Apr 21, 2024 at 12:32 AM David Hildenbrand <david@...hat.com> wrote:
>
> On 20.04.24 17:04, Lance Yang wrote:
> > On Sat, Apr 20, 2024 at 12:59 PM Lance Yang <ioworker0@...il.com> wrote:
> >>
> >> 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.
> >
> > 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.
>
Hey David,
Thanks a lot for clarifying!
> You must follow the exact same logic as in try_to_unmap_one() I guess.
Agreed. I'll take a closer look at try_to_unmap_one() and follow
the exact same logic - thanks!
>
> 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).
Yep, I understood. Could you please provide some suggestions on
where to place the exact same logic?
Thanks again for your time!
Lance
>
> --
> Cheers,
>
> David / dhildenb
>
Powered by blists - more mailing lists