Thread (32 messages) 32 messages, 5 authors, 2020-12-15

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
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help