On Tue, 7 Jul 2015 13:03:38 -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. Instead of forcing all locked pages to be present > when they are allocated, this set creates a middle ground. Pages are > marked to be placed on the unevictable LRU (locked) when they are first > used, but they are not faulted in by the mlock call. > > This series introduces a new mlock() system call that takes a flags > argument along with the start address and size. This flags argument > gives the caller the ability to request memory be locked in the > traditional way, or to be locked after the page is faulted in. New > calls are added for munlock() and munlockall() which give the called a > way to specify which flags are supposed to be cleared. A new MCL flag > is added to mirror the lock on fault behavior from mlock() in > mlockall(). Finally, a flag for mmap() is added that allows a user to > specify that the covered are should not be paged out, but only after the > memory has been used the first time. Thanks for sticking with this. Adding new syscalls is a bit of a hassle but I do think we end up with a better interface - the existing mlock/munlock/mlockall interfaces just aren't appropriate for these things. I don't know whether these syscalls should be documented via new manpages, or if we should instead add them to the existing mlock/munlock/mlockall manpages. Michael, could you please advise? -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
