On Tue 23-06-15 14:45:17, Vlastimil Babka wrote:

On 06/22/2015 04:18 PM, Eric B Munson wrote:

quoted

On Mon, 22 Jun 2015, Michal Hocko wrote:

quoted

On Fri 19-06-15 12:43:33, Eric B Munson wrote:

[...]

quoted

quoted

quoted

My thought on detecting was that someone might want to know if they had
a VMA that was VM_LOCKED but had not been made present becuase of a
failure in mmap.  We don't have a way today, but adding VM_LOCKONFAULT
is at least explicit about what is happening which would make detecting
the VM_LOCKED but not present state easier.

One could use /proc/<pid>/pagemap to query the residency.

I think that's all too much complex scenario for a little gain. If someone
knows that mmap(MAP_LOCKED|MAP_POPULATE) is not perfect, he should either
mlock() separately from mmap(), or fault the range manually with a for loop.
Why try to detect if the corner case was hit?

No idea. I have just offered a way to do that. I do not think it is
anyhow useful but who knows... I do agree that the mlock should be used
for the full mlock semantic.

quoted

quoted

quoted

This assumes that
MAP_FAULTPOPULATE does not translate to a VMA flag, but it sounds like
it would have to.

Yes, it would have to have a VM flag for the vma.

So with your approach, VM_LOCKED flag is enough, right? The new MAP_ /
MLOCK_ flags just cause setting VM_LOCKED to not fault the whole vma, but
otherwise nothing changes.

VM_FAULTPOPULATE would have to be sticky to prevent from other
speculative poppulation of the mapping. I mean, is it OK to have a new
mlock semantic (on fault) which might still populate&lock memory which
hasn't been faulted directly? Who knows what kind of speculative things
we will do in the future and then find out that the semantic of
lock-on-fault is not usable anymore.

[...]

-- 
Michal Hocko
SUSE Labs