Messages in this thread | | | Subject | Re: [PATCH v8 3/6] mm: Introduce VM_LOCKONFAULT | From | Vlastimil Babka <> | Date | Fri, 28 Aug 2015 16:54:16 +0200 |
| |
On 08/26/2015 08:24 PM, 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. > > For the example of a large file, this is the usage pattern for a large > statical language model (probably applies to other statical or graphical > models as well). For the security example, any application transacting > in data that cannot be swapped out (credit card data, medical records, > etc). > > This patch introduces the ability to request that pages are not > pre-faulted, but are placed on the unevictable LRU when they are finally > faulted in. The VM_LOCKONFAULT flag will be used together with > VM_LOCKED and has no effect when set without VM_LOCKED. Setting the > VM_LOCKONFAULT flag for a VMA will cause pages faulted into that VMA to > be added to the unevictable LRU when they are faulted or if they are > already present, but will not cause any missing pages to be faulted in. > > Exposing this new lock state means that we cannot overload the meaning > of the FOLL_POPULATE flag any longer. Prior to this patch it was used > to mean that the VMA for a fault was locked. This means we need the > new FOLL_MLOCK flag to communicate the locked state of a VMA. > FOLL_POPULATE will now only control if the VMA should be populated and > in the case of VM_LOCKONFAULT, it will not be set. > > Signed-off-by: Eric B Munson <emunson@akamai.com> > Cc: Michal Hocko <mhocko@suse.cz> > Cc: Vlastimil Babka <vbabka@suse.cz> > Cc: Jonathan Corbet <corbet@lwn.net> > Cc: "Kirill A. Shutemov" <kirill@shutemov.name> > Cc: linux-kernel@vger.kernel.org > Cc: linux-mm@kvack.org > Cc: linux-api@vger.kernel.org
Acked-by: Vlastimil Babka <vbabka@suse.cz>
I just wonder if the call to populate_vma_page_range from mprotect_fixup is just an potentially expensive no-op for VM_LOCKONFAULT vma's? It might find many cow candidates but faultin_page() won't do anything. And it shouldn't find any existing pages to put on the unevictable list from this context.
But it's a corner case and preventing it would mean putting in another VM_LOCKONFAULT check so maybe we can leave it like this. -
| |