Re: [Xen-devel] [PATCH XEN v8 24/29] tools/libs/call: linux: touch newly allocated pages after madvise lockdown

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Tue, 2016-01-19 at 15:49 +0000, Wei Liu wrote:
>Â
> I see. I wonder why we didn't use mlock(2) in Linux too in the first
> place.

We did, but mlock(2) on Linux doesn't guarantee that there will be no page
faults, it only guarantees that there will be no page faults which require
I/O to satisfy (~= it won't swap the page out).

Some text calls faults which require I/O "major" vs "minor" page faults
which don't need I/O to satisfy.

But Linux does things which can result in a supposedly locked PTE being not
present or not-writable, which results minor page faults. The main cause of
that is CoW due to fork (which affects both the parent and child). Other
ones could include being in the middle of moving pages between NUMA nodes
(current/source page is R/O) and THP (likewise content moving around).

BSD says (https://www.freebsd.org/cgi/man.cgi?query=mlock):

ÂÂÂÂÂAfter an mlock() system call, the indicated pages will cause neither a
ÂÂÂÂÂnon-resident page nor address-translation fault until they are unlocked.

which I think rules out both major and minor faults (i.e. faults of any
kind, which is what we need to pass the memory through to Xen).

Using madvise() instead of mlock() on Linux is really just a hack, in that
it gets us closer to the semantics we need, but isn't really the same.
Really we ought to provide a /dev/xen/foo from which memory can be
allocated with the right properties (much like /dev/xen/gntalloc does for
grantable memory).

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel