Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1179821
| From | Eric B Munson <emunson@akamai.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH V3 0/5] Allow user to request memory to be locked on page fault |
| Date | 2015-07-08 15:30 +0200 |
| Message-ID | <pJXAf-3fG-43@gated-at.bofh.it> (permalink) |
| References | <pJExz-8or-5@gated-at.bofh.it> <pJIrw-2mE-19@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
On Tue, 07 Jul 2015, Andrew Morton wrote: > 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? > Thanks for adding the series. I owe you several updates (getting the new syscall right for all architectures and a set of tests for the new syscalls). Would you prefer a new pair of patches or I update this set? Eric
Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread
[PATCH V3 0/5] Allow user to request memory to be locked on page fault Eric B Munson <emunson@akamai.com> - 2015-07-07 19:10 +0200
[PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it Eric B Munson <emunson@akamai.com> - 2015-07-07 19:20 +0200
Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it Jonathan Corbet <corbet@lwn.net> - 2015-07-10 18:20 +0200
Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it Eric B Munson <emunson@akamai.com> - 2015-07-10 18:30 +0200
[PATCH V3 1/5] mm: mlock: Refactor mlock, munlock, and munlockall code Eric B Munson <emunson@akamai.com> - 2015-07-07 19:20 +0200
Re: [PATCH V3 0/5] Allow user to request memory to be locked on page fault Eric B Munson <emunson@akamai.com> - 2015-07-08 15:30 +0200
csiph-web