lkml.org 
[lkml]   [2024]   [Mar]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Subject[PATCH v4 00/13] mm/gup: Unify hugetlb, part 2
    Date
    From: Peter Xu <peterx@redhat.com>

    v4:
    - Fix build issues, tested on more archs/configs ([x86_64, i386, arm, arm64,
    powerpc, riscv, s390] x [allno, alldef, allmod]).
    - Squashed the fixup series into v3, touched up commit messages [1]
    - Added the patch to fix pud_pfn() into the series [2]
    - Fixed one more build issue on arm+alldefconfig, where pgd_t is a
    two-item array.
    - Manage R-bs: add some, remove some (due to the squashes above)
    - Rebase to latest mm-unstable (2f6182cd23a7, March 26th)

    rfc: https://lore.kernel.org/r/20231116012908.392077-1-peterx@redhat.com
    v1: https://lore.kernel.org/r/20231219075538.414708-1-peterx@redhat.com
    v2: https://lore.kernel.org/r/20240103091423.400294-1-peterx@redhat.com
    v3: https://lore.kernel.org/r/20240321220802.679544-1-peterx@redhat.com

    The series removes the hugetlb slow gup path after a previous refactor work
    [1], so that slow gup now uses the exact same path to process all kinds of
    memory including hugetlb.

    For the long term, we may want to remove most, if not all, call sites of
    huge_pte_offset(). It'll be ideal if that API can be completely dropped
    from arch hugetlb API. This series is one small step towards merging
    hugetlb specific codes into generic mm paths. From that POV, this series
    removes one reference to huge_pte_offset() out of many others.

    One goal of such a route is that we can reconsider merging hugetlb features
    like High Granularity Mapping (HGM). It was not accepted in the past
    because it may add lots of hugetlb specific codes and make the mm code even
    harder to maintain. With a merged codeset, features like HGM can hopefully
    share some code with THP, legacy (PMD+) or modern (continuous PTEs).

    To make it work, the generic slow gup code will need to at least understand
    hugepd, which is already done like so in fast-gup. Due to the specialty of
    hugepd to be software-only solution (no hardware recognizes the hugepd
    format, so it's purely artificial structures), there's chance we can merge
    some or all hugepd formats with cont_pte in the future. That question is
    yet unsettled from Power side to have an acknowledgement. As of now for
    this series, I kept the hugepd handling because we may still need to do so
    before getting a clearer picture of the future of hugepd. The other reason
    is simply that we did it already for fast-gup and most codes are still
    around to be reused. It'll make more sense to keep slow/fast gup behave
    the same before a decision is made to remove hugepd.

    There's one major difference for slow-gup on cont_pte / cont_pmd handling,
    currently supported on three architectures (aarch64, riscv, ppc). Before
    the series, slow gup will be able to recognize e.g. cont_pte entries with
    the help of huge_pte_offset() when hstate is around. Now it's gone but
    still working, by looking up pgtable entries one by one.

    It's not ideal, but hopefully this change should not affect yet on major
    workloads. There's some more information in the commit message of the last
    patch. If this would be a concern, we can consider teaching slow gup to
    recognize cont pte/pmd entries, and that should recover the lost
    performance. But I doubt its necessity for now, so I kept it as simple as
    it can be.

    Test Done
    =========

    For x86_64, tested full gup_test matrix over 2MB huge pages. For aarch64,
    tested the same over 64KB cont_pte huge pages.

    One note is that this v3 didn't go through any ppc test anymore, as finding
    such system can always take time. It's based on the fact that it was
    tested in previous versions, and this version should have zero change
    regarding to hugepd sections.

    If anyone (Christophe?) wants to give it a shot on PowerPC, please do and I
    would appreciate it: "./run_vmtests.sh -a -t gup_test" should do well
    enough (please consider [2] applied if hugepd is <1MB), as long as we're
    sure the hugepd pages are touched as expected.

    Patch layout
    =============

    Patch 1-8: Preparation works, or cleanups in relevant code paths
    Patch 9-11: Teach slow gup with all kinds of huge entries (pXd, hugepd)
    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.

    [1] https://lore.kernel.org/all/20230628215310.73782-1-peterx@redhat.com
    [2] https://lore.kernel.org/r/20240321215047.678172-1-peterx@redhat.com

    Peter Xu (13):
    mm/Kconfig: CONFIG_PGTABLE_HAS_HUGE_LEAVES
    mm/hugetlb: Declare hugetlbfs_pagecache_present() non-static
    mm: Make HPAGE_PXD_* macros even if !THP
    mm: Introduce vma_pgtable_walk_{begin|end}()
    mm/arch: Provide pud_pfn() fallback
    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: Cache *pudp in follow_pud_mask()
    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: Handle hugetlb in the generic follow_page_mask code

    arch/riscv/include/asm/pgtable.h | 1 +
    arch/s390/include/asm/pgtable.h | 1 +
    arch/sparc/include/asm/pgtable_64.h | 1 +
    arch/x86/include/asm/pgtable.h | 1 +
    include/linux/huge_mm.h | 37 +-
    include/linux/hugetlb.h | 16 +-
    include/linux/mm.h | 3 +
    include/linux/pgtable.h | 10 +
    mm/Kconfig | 6 +
    mm/gup.c | 518 ++++++++++++++++++++--------
    mm/huge_memory.c | 133 +------
    mm/hugetlb.c | 75 +---
    mm/internal.h | 7 +-
    mm/memory.c | 12 +
    14 files changed, 441 insertions(+), 380 deletions(-)

    --
    2.44.0


    \
     
     \ /
      Last update: 2024-05-27 16:12    [W:5.800 / U:0.096 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site