Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1190019
| From | Eric B Munson <emunson@akamai.com> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH V4 5/6] mm: mmap: Add mmap flag to request VM_LOCKONFAULT |
| Date | 2015-07-22 16:40 +0200 |
| Message-ID | <pP3lD-19S-5@gated-at.bofh.it> (permalink) |
| References | <pOLRL-1hK-3@gated-at.bofh.it> <pOM1s-1Il-19@gated-at.bofh.it> <pP0nL-5o8-1@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
[Multipart message — attachments visible in raw view] - view raw
On Wed, 22 Jul 2015, Kirill A. Shutemov wrote: > On Tue, Jul 21, 2015 at 03:59:40PM -0400, Eric B Munson wrote: > > The cost of faulting in all memory to be locked can be very high when > > working with large mappings. If only portions of the mapping will be > > used this can incur a high penalty for locking. > > > > Now that we have the new VMA flag for the locked but not present state, > > expose it as an mmap option like MAP_LOCKED -> VM_LOCKED. > > What is advantage over mmap() + mlock(MLOCK_ONFAULT)? There isn't one, it was added to maintain parity with the mlock(MLOCK_LOCK) -> mmap(MAP_LOCKED) set. I think not having will lead to confusion because we have MAP_LOCKED so why don't we support LOCKONFAULT from mmap as well.
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [PATCH V4 5/6] mm: mmap: Add mmap flag to request VM_LOCKONFAULT "Kirill A. Shutemov" <kirill@shutemov.name> - 2015-07-22 13:30 +0200
Re: [PATCH V4 5/6] mm: mmap: Add mmap flag to request VM_LOCKONFAULT Eric B Munson <emunson@akamai.com> - 2015-07-22 16:40 +0200
Re: [PATCH V4 5/6] mm: mmap: Add mmap flag to request VM_LOCKONFAULT "Kirill A. Shutemov" <kirill@shutemov.name> - 2015-07-22 17:50 +0200
csiph-web