On 2/6/22 22:36, Hugh Dickins wrote: > Add vma argument to mlock_vma_page() and munlock_vma_page(), make them > inline functions which check (vma->vm_flags & VM_LOCKED) before calling > mlock_page() and munlock_page() in mm/mlock.c. > > Add bool compound to mlock_vma_page() and munlock_vma_page(): this is > because we have understandable difficulty in accounting pte maps of THPs, > and if passed a PageHead page, mlock_page() and munlock_page() cannot > tell whether it's a pmd map to be counted or a pte map to be ignored. > > Add vma arg to page_add_file_rmap() and page_remove_rmap(), like the > others, and use that to call mlock_vma_page() at the end of the page > adds, and munlock_vma_page() at the end of page_remove_rmap() (end or > beginning? unimportant, but end was easier for assertions in testing). > > No page lock is required (although almost all adds happen to hold it): > delete the "Serialize with page migration" BUG_ON(!PageLocked(page))s. > Certainly page lock did serialize with page migration, but I'm having > difficulty explaining why that was ever important. > > Mlock accounting on THPs has been hard to define, differed between anon > and file, involved PageDoubleMap in some places and not others, required > clear_page_mlock() at some points. Keep it simple now: just count the > pmds and ignore the ptes, there is no reason for ptes to undo pmd mlocks. > > page_add_new_anon_rmap() callers unchanged: they have long been calling > lru_cache_add_inactive_or_unevictable(), which does its own VM_LOCKED > handling (it also checks for not VM_SPECIAL: I think that's overcautious, > and inconsistent with other checks, that mmap_region() already prevents > VM_LOCKED on VM_SPECIAL; but haven't quite convinced myself to change it). > > Signed-off-by: Hugh Dickins <hughd@xxxxxxxxxx> Yeah, much better when most of the sites are encapsulated in rmap operations like this. Acked-by: Vlastimil Babka <vbabka@xxxxxxx>
