mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [PATCH RFC v2 0/9] mm/huge_memory: refactor __split_huge_pmd_locked()
@ 2026-11-10 17:59 Yin Tirui
  2026-11-10 17:59 ` [PATCH RFC v2 1/9] mm/huge_memory: read the huge PMD entry once when splitting it Yin Tirui
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: Yin Tirui @ 2026-11-10 17:59 UTC (permalink / raw)
  To: akpm, david, ziy
  Cc: ljs, dev.jain, baolin.wang, baohua, lance.yang, ryan.roberts,
	nico.pache, usama.arif, liam, kas, wangkefeng.wang, chenjun102,
	yintirui, linux-kernel, linux-mm

__split_huge_pmd_locked() currently decides from the VMA --
vma_is_anonymous(), then vma_is_special_huge() (now replaced by
!vma_is_mm_managed()) -- before inspecting the PMD entry, so split and
zap use different classification logic. 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.

v1 -> v2:
https://lore.kernel.org/linux-mm/cover.1787941780.git.yintirui@gmail.com/#t
- Rebase onto mainline.
- Use !vma_is_mm_managed() in place of vma_is_special_huge() in patch 3.
- Use vma_has_deposited_pgtable() in patch 4, following Lance Yang's
  pgtable deposit cleanup.
  https://lore.kernel.org/linux-mm/20260917054015.23553-1-lance.yang@linux.dev/

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


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2026-11-10 18:01 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-11-10 17:59 [PATCH RFC v2 0/9] mm/huge_memory: refactor __split_huge_pmd_locked() Yin Tirui
2026-11-10 17:59 ` [PATCH RFC v2 1/9] mm/huge_memory: read the huge PMD entry once when splitting it Yin Tirui
2026-11-10 17:59 ` [PATCH RFC v2 2/9] mm/huge_memory: add and use huge_zero_pmd_can_split() Yin Tirui
2026-11-10 17:59 ` [PATCH RFC v2 3/9] mm/huge_memory: add and use unmap_huge_pmd_entry() Yin Tirui
2026-11-10 17:59 ` [PATCH RFC v2 4/9] mm/huge_memory: use normal_or_softleaf_folio_pmd() in the PMD split path Yin Tirui
2026-11-10 17:59 ` [PATCH RFC v2 5/9] mm/huge_memory: dispatch on the folio when splitting a huge PMD Yin Tirui
2026-11-10 17:59 ` [PATCH RFC v2 6/9] mm/huge_memory: add and use split_huge_pmd_anon_rmap() Yin Tirui
2026-11-10 17:59 ` [PATCH RFC v2 7/9] mm/huge_memory: add struct split_pmd_state Yin Tirui
2026-11-10 17:59 ` [PATCH RFC v2 8/9] mm/huge_memory: split present and non-present huge PMDs separately Yin Tirui
2026-11-10 17:59 ` [PATCH RFC v2 9/9] mm/huge_memory: unify the migration and device private PTE loops Yin Tirui

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®