Re: [PATCH mm-unstable v18 06/14] mm/khugepaged: generalize collapse_huge_page for mTHP collapse
From: Nico Pache <hidden>
Date: 2026-06-04 17:03:57
Also in:
linux-doc, linux-mm, lkml
On Mon, Jun 1, 2026 at 9:00 AM Nico Pache [off-list ref] wrote:
On Mon, Jun 1, 2026 at 5:14 AM David Hildenbrand (Arm) [off-list ref] wrote:quoted
On 6/1/26 12:47, Lance Yang wrote:quoted
On 2026/6/1 18:23, David Hildenbrand (Arm) wrote:quoted
On 6/1/26 11:08, Lance Yang wrote:quoted
One small thing, I think we should probably keep the smp_wmb(), and just move it before the earlier pmd_populate(). IIUC, the ordering we want is still: clear old PTEs smp_wmb() pmd_populate() so another CPU cannot walk through the re-installed PMD and still observe the old PTEs, right?There is a smp_wmb() in __folio_mark_uptodate(), that should be sufficient?Ah, cool! __folio_mark_uptodate() already does the job :P So yeah, no extra smp_wmb() needed here!Yeah. BTW, I think we'd need a spin_lock_nested(), so @Nico, treat my code as a draft.Okay, I read the above and did some investigating. I will try to implement and verify the changes you suggested :)
I've implemented something slightly different actually and I *think* its better!
} else {
/* this is map_anon_folio_pte_nopf with no mmu update */
__map_anon_folio_pte_nopf(folio, pte, vma, start_addr,
/*uffd_wp=*/ false);
smp_wmb();
pmd_populate(mm, pmd, pmd_pgtable(_pmd));
/*
* Some architectures (e.g. MIPS) walk the live page table in
* their implementation. update_mmu_cache_range() must be called
* with a valid page table hierarchy and the PTE lock held.
* Acquire it nested inside pmd_ptl when they are distinct locks.
*/
if (pte_ptl != pmd_ptl)
spin_lock_nested(pte_ptl, SINGLE_DEPTH_NESTING);
update_mmu_cache_range(NULL, vma, start_addr, pte, nr_pages);
if (pte_ptl != pmd_ptl)
spin_unlock(pte_ptl);
}
spin_unlock(pmd_ptl);
The logic here is that when the PMD becomes visible, PTEs are already
populated (no possibility of spurious faults on local CPU)
the SMP_WMB makes sure of the above
And the pmd is installed with the pte and pmd lock both held through
the mmu_cache update.
This follows the conventions used in pmd_install() and clears the
potential for local CPU faults hitting cleared PTE entries.
I think both approaches are correct but this prevents any possibility
of my first point. although mmap_write_lock prevents this too.
Let me know what you think. I can revert to your implementation but
this is what I tested.
Cheers,
-- Nico
Or an even crazier idea... what if we ensure MIPS checks for PMD_none before walking a PTE table? -- Nicoquoted
-- Cheers, David