On Fri, Apr 14, 2023 at 11:00:43AM -0700, Suren Baghdasaryan wrote: > When page fault is handled under VMA lock protection, all swap page > faults are retried with mmap_lock because folio_lock_or_retry > implementation has to drop and reacquire mmap_lock if folio could > not be immediately locked. > Instead of retrying all swapped page faults, retry only when folio > locking fails. Reviewed-by: Matthew Wilcox (Oracle) <willy@xxxxxxxxxxxxx> Let's just review what can now be handled under the VMA lock instead of the mmap_lock, in case somebody knows better than me that it's not safe. - We can call migration_entry_wait(). This will wait for PG_locked to become clear (in migration_entry_wait_on_locked()). As previously discussed offline, I think this is safe to do while holding the VMA locked. - We can call remove_device_exclusive_entry(). That calls folio_lock_or_retry(), which will fail if it can't get the VMA lock. - We can call pgmap->ops->migrate_to_ram(). Perhaps somebody familiar with Nouveau and amdkfd could comment on how safe this is? - I believe we can't call handle_pte_marker() because we exclude UFFD VMAs earlier. - We can call swap_readpage() if we allocate a new folio. I haven't traced through all this code to tell if it's OK. So ... I believe this is all OK, but we're definitely now willing to wait for I/O from the swap device while holding the VMA lock when we weren't before. And maybe we should make a bigger deal of it in the changelog. And maybe we shouldn't just be failing the folio_lock_or_retry(), maybe we should be waiting for the folio lock with the VMA locked.
