Messages in this thread | | | From | David Hildenbrand <> | Subject | Re: [PATCH v3 5/6] mm/gup: migrate pinned pages out of movable zone | Date | Sat, 12 Dec 2020 08:29:11 +0100 |
| |
> Am 12.12.2020 um 00:50 schrieb Jason Gunthorpe <jgg@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 >
| |