[PATCH RFC 0/9] mm/huge_memory: refactor __split_huge_pmd_locked()

Yin Tirui posted 9 patches 4 weeks, 1 day ago
mm/huge_memory.c | 525 +++++++++++++++++++++++++++--------------------
1 file changed, 302 insertions(+), 223 deletions(-)
[PATCH RFC 0/9] mm/huge_memory: refactor __split_huge_pmd_locked()
Posted by Yin Tirui 4 weeks, 1 day ago
__split_huge_pmd_locked() currently decides from the VMA --
vma_is_anonymous(), then vma_is_special_huge() -- before inspecting the PMD
entry, so split and zap can classify the same PMD differently. The entry
itself should decide. The function also mixes the present and non-present
cases, resulting in duplicated code.

This series uses the PMD entry and its folio to decide how to handle each
PMD, as zap_huge_pmd() does. It separates the present and non-present paths
and moves their common work into helper functions. After this change,
__split_huge_pmd_locked() only selects the appropriate helper.

Yin Tirui (9):
  mm/huge_memory: read the huge PMD entry once when splitting it
  mm/huge_memory: add and use huge_zero_pmd_can_split()
  mm/huge_memory: add and use unmap_huge_pmd_entry()
  mm/huge_memory: use normal_or_softleaf_folio_pmd() in the PMD split
    path
  mm/huge_memory: dispatch on the folio when splitting a huge PMD
  mm/huge_memory: add and use split_huge_pmd_anon_rmap()
  mm/huge_memory: add struct split_pmd_state
  mm/huge_memory: split present and non-present huge PMDs separately
  mm/huge_memory: unify the migration and device private PTE loops

 mm/huge_memory.c | 525 +++++++++++++++++++++++++++--------------------
 1 file changed, 302 insertions(+), 223 deletions(-)

-- 
2.34.1
Re: [PATCH RFC 0/9] mm/huge_memory: refactor __split_huge_pmd_locked()
Posted by David Hildenbrand (Arm) 2 weeks, 1 day ago
On 8/28/26 20:33, Yin Tirui wrote:
> __split_huge_pmd_locked() currently decides from the VMA --
> vma_is_anonymous(), then vma_is_special_huge() -- before inspecting the PMD
> entry, so split and zap can classify the same PMD differently. The entry
> itself should decide. The function also mixes the present and non-present
> cases, resulting in duplicated code.
> 
> This series uses the PMD entry and its folio to decide how to handle each
> PMD, as zap_huge_pmd() does. It separates the present and non-present paths
> and moves their common work into helper functions. After this change,
> __split_huge_pmd_locked() only selects the appropriate helper.

I skimmed over some of the patches and there seems to be valuable cleanups in
there. As the MM list is right now extremely busy, I won't be able to review
this right now, so unfortunately this will have to wait.

-- 
Cheers,

David