Re: [RESEND PATCH V2 0/3] Allow user to request memory to be locked on page fault

On Tue, 23 Jun 2015, Vlastimil Babka wrote:

On 06/15/2015 04:43 PM, Eric B Munson wrote:

quoted

quoted

Note that the semantic of MAP_LOCKED can be subtly surprising:

"mlock(2) fails if the memory range cannot get populated to guarantee
that no future major faults will happen on the range.
mmap(MAP_LOCKED) on the other hand silently succeeds even if the
range was populated only
partially."

( from http://marc.info/?l=linux-mm&m=143152790412727&w=2 )

So MAP_LOCKED can silently behave like MAP_LOCKONFAULT. While
MAP_LOCKONFAULT doesn't suffer from such problem, I wonder if that's
sufficient reason not to extend mmap by new mlock() flags that can
be instead applied to the VMA after mmapping, using the proposed
mlock2() with flags. So I think instead we could deprecate
MAP_LOCKED more prominently. I doubt the overhead of calling the
extra syscall matters here?

We could talk about retiring the MAP_LOCKED flag but I suspect that
would get significantly more pushback than adding a new mmap flag.

Oh no we can't "retire" as in remove the flag, ever. Just not
continue the way of mmap() flags related to mlock().

quoted

Likely that the overhead does not matter in most cases, but presumably
there are cases where it does (as we have a MAP_LOCKED flag today).
Even with the proposed new system calls I think we should have the
MAP_LOCKONFAULT for parity with MAP_LOCKED.

I'm not convinced, but it's not a major issue.

quoted

quoted

quoted

- mlock() takes a `flags' argument.  Presently that's
  MLOCK_LOCKED|MLOCK_LOCKONFAULT.

- munlock() takes a `flags' arument.  MLOCK_LOCKED|MLOCK_LOCKONFAULT
  to specify which flags are being cleared.

- mlockall() and munlockall() ditto.


IOW, LOCKED and LOCKEDONFAULT are treated identically and independently.

Now, that's how we would have designed all this on day one.  And I
think we can do this now, by adding new mlock2() and munlock2()
syscalls.  And we may as well deprecate the old mlock() and munlock(),
not that this matters much.

*should* we do this?  I'm thinking "yes" - it's all pretty simple
boilerplate and wrappers and such, and it gets the interface correct,
and extensible.

If the new LOCKONFAULT functionality is indeed desired (I haven't
still decided myself) then I agree that would be the cleanest way.

Do you disagree with the use cases I have listed or do you think there
is a better way of addressing those cases?

I'm somewhat sceptical about the security one. Are security
sensitive buffers that large to matter? The performance one is more
convincing and I don't see a better way, so OK.

They can be, the two that come to mind are medical images and high
resolution sensor data.

quoted

quoted

quoted

What do others think?