Re: [RFC PATCH 00/57] mm/collapse: rebuild collapse on migration primitives

On Tue, Aug 18, 2026 at 04:15:27PM +0200, David Hildenbrand (Arm) wrote:
> > David and I talked about this at LSF/MM. 
> 
> Ah, I missed the context in my other reply. Lorenzo already had some patches at
> some point to split up mm/memory.c into better chunks that will also better help
> our subcomponent maintenance model.

Lorenzo, if you can dig those out, I would rather build on them than start
over.  Happy to do the legwork.

> I think the challenge is how to handle huge_memory.c, because ideally, we'd not
> have these stupid callbacks into huge_memory.c once we make PMDs just a
> first-class citizen.

Agreed on settling the target shape before moving anything.

Splitting by operation answers most of huge_memory.c on its own, though.

Its entry points are named after the operation they implement, and each has
one destination: do_huge_pmd_anonymous_page(), do_huge_pmd_wp_page() and
do_huge_pmd_numa_page() belong next to do_anonymous_page() in
mm/fault.c.

zap_huge_pmd() next to zap_pte_range(), copy_huge_pmd() next to
copy_pte_range().  change_huge_pmd(), move_huge_pmd() and follow_huge_pmd()
have their callers in the right file already -- mprotect.c, mremap.c, gup.c
-- so they move to the caller.  The callback goes away because the PMD case
becomes a branch beside the PTE case instead of a call into another file.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov