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
