On Fri, 29 May 2015 10:13:25 -0400 Eric B Munson <emunson@xxxxxxxxxx> wrote: > 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. - 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 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? - Can we rename patch 1/3 from "add flag to ..." to "add mmap flag to ...", to distinguish from 2/3 "add mlockall flag ..."? - 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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>