> Am 12.12.2020 um 00:50 schrieb Jason Gunthorpe <j...@ziepe.ca>: > > On Fri, Dec 11, 2020 at 10:53:00PM +0100, David Hildenbrand wrote: > >>> When check_and_migrate_movable_pages() is called, the pages are >>> already pinned. If some of those pages are in movable zone, and we >>> fail to migrate or isolate them what should we do: proceed, and >>> keep it as exception of when movable zone can actually have pinned >>> pages or unpin all pages in the array, and return an error, or >>> unpin only pages in movable zone, and return an error? >> >> I guess revert what we did (unpin) and return an error. The >> interesting question is what can make migration/isolation fail >> >> a) out of memory: smells like a zone setup issue. Failures are acceptable I >> guess. > > Out of memory is reasonable.. > >> b) short term pinnings: process dying - not relevant I guess. Other cases? >> (Fork?) > > Concurrent with non-longterm GUP users are less reasonable, fork is > not reasonable, etc..
Concurrent alloc_contig_range(), memory offlining, compaction .. where we migrate pages? Any experts on racing page migration in these scenarios? (Also wondering what would happen if we are just about to swap) > > Racing with another GUP in another thread is also not reasonable, so > failing to isolate can't be a failure Having VMs with multiple vfio containers is certainly realistic, and optimizing in user space to do vfio mappings concurrently doesn‘t sound too crazy to me. But I haven‘t checked if vfio common code already handles such concurrency. > > Jasnon >
