lkml.org 
[lkml]   [2020]   [Dec]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH v3 5/6] mm/gup: migrate pinned pages out of movable zone
Date

> 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
>

\
 
 \ /
  Last update: 2020-12-12 11:39    [W:0.127 / U:1.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site