mbox series

[v4,0/3] Reclaim lazyfree THP without splitting

Message ID 20240501042700.83974-1-ioworker0@gmail.com (mailing list archive)
Headers show
Series Reclaim lazyfree THP without splitting | expand

Message

Lance Yang May 1, 2024, 4:26 a.m. UTC
Hi all,

This series adds support for reclaiming PMD-mapped THP marked as lazyfree
without needing to first split the large folio via split_huge_pmd_address().

When the user no longer requires the pages, they would use madvise(MADV_FREE)
to mark the pages as lazy free. Subsequently, they typically would not re-write
to that memory again.

During memory reclaim, if we detect that the large folio and its PMD are both
still marked as clean and there are no unexpected references(such as GUP), so we
can just discard the memory lazily, improving the efficiency of memory
reclamation in this case.

Performance Testing
===================

On an Intel i5 CPU, reclaiming 1GiB of lazyfree 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% |
--------------------------------------------

---

Changes since v3 [3]
====================
 - mm/rmap: integrate PMD-mapped folio splitting into pagewalk loop
    - Resolve compilation errors by handling the case where
      CONFIG_PGTABLE_HAS_HUGE_LEAVES is undefined (thanks to SeongJae Park)
 - mm/vmscan: avoid split lazyfree THP during shrink_folio_list()
    - Remove the unnecessary conditional compilation directives
      (thanks to Barry Song)
    - Resolve compilation errors due to undefined references to
      unmap_huge_pmd_locked and split_huge_pmd_locked (thanks to Barry)

Changes since v2 [2]
====================
 - Update the changelog (thanks to David Hildenbrand)
 - Support try_to_unmap_one() to unmap PMD-mapped folios
   (thanks a lot to David Hildenbrand and Zi Yan)

Changes since v1 [1]
====================
 - Update the changelog
 - Follow the exact same logic as in try_to_unmap_one() (per David Hildenbrand)
 - Remove the extra code from rmap.c (per Matthew Wilcox)

[1] https://lore.kernel.org/linux-mm/20240417141111.77855-1-ioworker0@gmail.com
[2] https://lore.kernel.org/linux-mm/20240422055213.60231-1-ioworker0@gmail.com
[3] https://lore.kernel.org/linux-mm/20240429132308.38794-1-ioworker0@gmail.com

Lance Yang (3):
  mm/rmap: remove duplicated exit code in pagewalk loop
  mm/rmap: integrate PMD-mapped folio splitting into pagewalk loop
  mm/vmscan: avoid split lazyfree THP during shrink_folio_list()

 include/linux/huge_mm.h |  29 ++++++++++
 mm/huge_memory.c        | 115 +++++++++++++++++++++++++++++++++-------
 mm/rmap.c               |  67 ++++++++++++-----------
 3 files changed, 160 insertions(+), 51 deletions(-)

Comments

SeongJae Park May 1, 2024, 4:08 p.m. UTC | #1
Hi Lance,

On Wed,  1 May 2024 12:26:57 +0800 Lance Yang <ioworker0@gmail.com> wrote:

> Hi all,
> 
> This series adds support for reclaiming PMD-mapped THP marked as lazyfree
> without needing to first split the large folio via split_huge_pmd_address().
> 
> When the user no longer requires the pages, they would use madvise(MADV_FREE)
> to mark the pages as lazy free. Subsequently, they typically would not re-write
> to that memory again.
> 
> During memory reclaim, if we detect that the large folio and its PMD are both
> still marked as clean and there are no unexpected references(such as GUP), so we
> can just discard the memory lazily, improving the efficiency of memory
> reclamation in this case.
> 
> Performance Testing
> ===================
> 
> On an Intel i5 CPU, reclaiming 1GiB of lazyfree 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% |
> --------------------------------------------
> 
> ---
> 
> Changes since v3 [3]
> ====================
>  - mm/rmap: integrate PMD-mapped folio splitting into pagewalk loop
>     - Resolve compilation errors by handling the case where
>       CONFIG_PGTABLE_HAS_HUGE_LEAVES is undefined (thanks to SeongJae Park)

I confirmed that the issue I reported before is disappeared with this version
of the patchset.  For the fix,

Tested-by: SeongJae Park <sj@kernel.org>


Thanks,
SJ

[...]
Lance Yang May 2, 2024, 12:30 a.m. UTC | #2
On Thu, May 2, 2024 at 12:08 AM SeongJae Park <sj@kernel.org> wrote:
>
> Hi Lance,
>
> On Wed,  1 May 2024 12:26:57 +0800 Lance Yang <ioworker0@gmail.com> wrote:
>
> > Hi all,
> >
> > This series adds support for reclaiming PMD-mapped THP marked as lazyfree
> > without needing to first split the large folio via split_huge_pmd_address().
> >
> > When the user no longer requires the pages, they would use madvise(MADV_FREE)
> > to mark the pages as lazy free. Subsequently, they typically would not re-write
> > to that memory again.
> >
> > During memory reclaim, if we detect that the large folio and its PMD are both
> > still marked as clean and there are no unexpected references(such as GUP), so we
> > can just discard the memory lazily, improving the efficiency of memory
> > reclamation in this case.
> >
> > Performance Testing
> > ===================
> >
> > On an Intel i5 CPU, reclaiming 1GiB of lazyfree 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% |
> > --------------------------------------------
> >
> > ---
> >
> > Changes since v3 [3]
> > ====================
> >  - mm/rmap: integrate PMD-mapped folio splitting into pagewalk loop
> >     - Resolve compilation errors by handling the case where
> >       CONFIG_PGTABLE_HAS_HUGE_LEAVES is undefined (thanks to SeongJae Park)
>
> I confirmed that the issue I reported before is disappeared with this version
> of the patchset.  For the fix,
>
> Tested-by: SeongJae Park <sj@kernel.org>

Hey SJ,

Thanks for taking time to confirm! I appreciate your feedback!

Thanks,
Lance

>
>
> Thanks,
> SJ
>
> [...]