Re: [PATCH v3 5/6] mm/gup: migrate pinned pages out of movable zone
From: David Hildenbrand <hidden>
Date: 2020-12-12 10:38:32
Also in:
linux-mm, lkml
Am 12.12.2020 um 00:50 schrieb Jason Gunthorpe [off-list ref]: On Fri, Dec 11, 2020 at 10:53:00PM +0100, David Hildenbrand wrote:quoted
quoted
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..quoted
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