lkml.org 
[lkml]   [2015]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH V3 0/5] Allow user to request memory to be locked on page fault
On Tue,  7 Jul 2015 13:03:38 -0400 Eric B Munson <emunson@akamai.com> 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?



\
 
 \ /
  Last update: 2015-07-07 23:41    [W:0.210 / U:0.584 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site