mbox series

[RFC,00/12] mm/gup: Unify hugetlb, part 2

Message ID 20231116012908.392077-1-peterx@redhat.com
Headers
Series mm/gup: Unify hugetlb, part 2 |

Message

Peter Xu Nov. 16, 2023, 1:28 a.m. UTC 
  This patchset is in RFC stage. It's mostly because it is only yet tested on
x86_64 in a VM.  Not even compile tested on PPC or any other archs, it
means at least the hugepd patch (patch 11) is mostly untested, or even not
compile tested.  Before doing that, I'd like to collect any information
from high level.

If anyone would like to provide any testing either over hugepd or CONT_PMD
/ CONT_PTE on ARM (before I reach there..), or RISCV over 64K Svnapot,
that'll be very much appreciated.  I'm copying PPC, ARM, RISCV list for
that.  It can be as simple as "./run_vmtests.sh -t gup_test -a" for now,
making sure hugetlb pages can be allocated along the way; the non-hugetlb
gup tests will guaranteed to be covered more or less, I suppose.

In summary, this is a continuous work for previous series:

https://lore.kernel.org/all/20230628215310.73782-1-peterx@redhat.com

And this more or less is my current take to move one more small step
towards merging hugetlb code into generic mm code, as much as we can.

That part-1 series dropped follow_hugetlb_page().  The plan of this one is
to further drops hugetlb_follow_page_mask().  The hugetlb GUP will use the
same code path for generic mm after whole set applied.

It means the generic code will need to at least understand hugepd, and
that's already done like so in fast-gup.  Fortunately it seems that's the
only major thing I need to teach GUP to share the common path for now
besides normal huge PxD entries.  Non-gup can be more challenging, but
that's a question for later.

Patch layout:
=============

Patch 1-4:    Preparation works, mm generic part
Patch 5-6:    Bugfixes; I think patch 5 if verified can be merged earlier
Patch 7-11:   Preparation works, gup part
Patch 12:     Drop hugetlb_follow_page_mask()

More information can be found in the commit messages of each patch.  Any
comment will be welcomed.  Thanks.

Peter Xu (12):
  mm/hugetlb: Export hugetlbfs_pagecache_present()
  mm: Provide generic pmd_thp_or_huge()
  mm: Export HPAGE_PXD_* macros even if !THP
  mm: Introduce vma_pgtable_walk_{begin|end}()
  mm/gup: Fix follow_devmap_p[mu]d() to return even if NULL
  mm/gup: Drop folio_fast_pin_allowed() in hugepd processing
  mm/gup: Refactor record_subpages() to find 1st small page
  mm/gup: Handle hugetlb for no_page_table()
  mm/gup: Handle huge pud for follow_pud_mask()
  mm/gup: Handle huge pmd for follow_pmd_mask()
  mm/gup: Handle hugepd for follow_page()
  mm/gup: Merge hugetlb into generic mm code

 include/linux/huge_mm.h |  34 +++----
 include/linux/hugetlb.h |  10 +-
 include/linux/mm.h      |   3 +
 include/linux/pgtable.h |   4 +
 mm/gup.c                | 197 +++++++++++++++++++++++++---------------
 mm/huge_memory.c        | 117 +++++++++++++-----------
 mm/hugetlb.c            |  75 +--------------
 mm/internal.h           |   6 +-
 mm/memory.c             |  12 +++
 9 files changed, 233 insertions(+), 225 deletions(-)

Comments

Jason Gunthorpe Nov. 22, 2023, 2:51 p.m. UTC | #1 
On Wed, Nov 15, 2023 at 08:28:56PM -0500, Peter Xu wrote:
> This patchset is in RFC stage. It's mostly because it is only yet tested on
> x86_64 in a VM.  Not even compile tested on PPC or any other archs, it
> means at least the hugepd patch (patch 11) is mostly untested, or even not
> compile tested.  Before doing that, I'd like to collect any information
> from high level.
> 
> If anyone would like to provide any testing either over hugepd or CONT_PMD
> / CONT_PTE on ARM (before I reach there..), or RISCV over 64K Svnapot,
> that'll be very much appreciated.  I'm copying PPC, ARM, RISCV list for
> that.  It can be as simple as "./run_vmtests.sh -t gup_test -a" for now,
> making sure hugetlb pages can be allocated along the way; the non-hugetlb
> gup tests will guaranteed to be covered more or less, I suppose.
> 
> In summary, this is a continuous work for previous series:
> 
> https://lore.kernel.org/all/20230628215310.73782-1-peterx@redhat.com
> 
> And this more or less is my current take to move one more small step
> towards merging hugetlb code into generic mm code, as much as we can.
> 
> That part-1 series dropped follow_hugetlb_page().  The plan of this one is
> to further drops hugetlb_follow_page_mask().  The hugetlb GUP will use the
> same code path for generic mm after whole set applied.
> 
> It means the generic code will need to at least understand hugepd, and
> that's already done like so in fast-gup.  Fortunately it seems that's the
> only major thing I need to teach GUP to share the common path for now
> besides normal huge PxD entries.  Non-gup can be more challenging, but
> that's a question for later.

This is great, I looked through quickly and didn't have any profound remarks

Thanks,
Jason