On Sun, Aug 16, 2026 at 10:02:53PM -0400, Zi Yan wrote: > > What that removes from every collapse path: > > > > mmap_write_lock -> mmap_read > > anon_vma_lock_write() -> nothing: an rmap walk needs the folio > > locked, and the engine holds that lock > > from freeze to putback > > tlb_remove_table_sync_one() -> nothing: one ranged flush per round > > LRU isolation -> nothing: sources are inert in place > > I remember we were discussing using migration entry and the issue with > mmap_write_lock() in the context of in-place THP promotion and the > conclusion was that because MADV_DONTNEED (maybe MADV_REMOVE or > MADV_PAGEOUT) works on page table and does not change VMAs, > mmap_write_lock() is needed to prevent things being changed under > khugepaged. Anything different in normal khugepaged collapse process, so > that it is OK to use mmap_read_lock? Let me know if I misremember it.
IIRC that discussion predates Hugh's pte_offset_map() rework -- since 0d940a9b270b the helper takes rcu_read_lock() and fails if the pmd is none, !present or huge, so mmap_write is no longer what keeps a pte walker out. MADV_DONTNEED is still not excluded, and the engine does not try to: the install re-reads every slot under the ptl and publishes only if it still holds the migration entry this round put there, leaving a zapped slot alone and dropping the rmap the frozen source still held. -- Kiryl Shutsemau / Kirill A. Shutemov
