On Mon, 01 Jun 2015, Andrew Morton wrote:

On Fri, 29 May 2015 10:13:25 -0400 Eric B Munson [off-list ref] wrote:

quoted

mlock() allows a user to control page out of program memory, but this
comes at the cost of faulting in the entire mapping when it is
allocated.  For large mappings where the entire area is not necessary
this is not ideal.

This series introduces new flags for mmap() and mlockall() that allow a
user to specify that the covered are should not be paged out, but only
after the memory has been used the first time.

I almost applied these, but the naming issue (below) stopped me.

A few things...

- The 0/n changelog should reveal how MAP_LOCKONFAULT interacts with
  rlimit(RLIMIT_MEMLOCK).

  I see the implementation is "as if the entire mapping will be
  faulted in" (for mmap) and "as if it was MCL_FUTURE" (for mlockall)
  which seems fine.  Please include changelog text explaining and
  justifying these decisions.  This stuff will need to be in the
  manpage updates as well.

Change logs are updated, and this will be included in the man page
update as well.

- I think I already asked "why not just use MCL_FUTURE" but I forget
  the answer ;) In general it is a good idea to update changelogs in
  response to reviewer questions, because other people will be
  wondering the same things.  Or maybe I forgot to ask.  Either way,
  please address this in the changelogs.

I must have missed that question.  Here is the text from the updated
mlockall changelog:

MCL_ONFAULT is preferrable to MCL_FUTURE for the use cases enumerated
in the previous patch becuase MCL_FUTURE will behave as if each mapping
was made with MAP_LOCKED, causing the entire mapping to be faulted in
when new space is allocated or mapped.  MCL_ONFAULT allows the user to
delay the fault in cost of any given page until it is actually needed,
but then guarantees that that page will always be resident.

- I can perhaps see the point in mmap(MAP_LOCKONFAULT) (other
  mappings don't get lock-in-memory treatment), but what's the benefit
  in mlockall(MCL_ON_FAULT) over MCL_FUTURE?  (Add to changelog also,
  please).

- Is there a manpage update?

I will send one out when I post V2

- Can we rename patch 1/3 from "add flag to ..." to "add mmap flag to
  ...", to distinguish from 2/3 "add mlockall flag ..."?

Done

- The MAP_LOCKONFAULT versus MCL_ON_FAULT inconsistency is
  irritating!  Can we get these consistent please: switch to either
  MAP_LOCK_ON_FAULT or MCL_ONFAULT.

Yes, will do for V2.