Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752772AbbH1OyV (ORCPT ); Fri, 28 Aug 2015 10:54:21 -0400 Received: from mx2.suse.de ([195.135.220.15]:52800 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751754AbbH1OyU (ORCPT ); Fri, 28 Aug 2015 10:54:20 -0400 Subject: Re: [PATCH v8 3/6] mm: Introduce VM_LOCKONFAULT To: Eric B Munson , Andrew Morton References: <1440613465-30393-1-git-send-email-emunson@akamai.com> <1440613465-30393-4-git-send-email-emunson@akamai.com> Cc: Michal Hocko , Jonathan Corbet , "Kirill A. Shutemov" , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-api@vger.kernel.org From: Vlastimil Babka Message-ID: <55E07618.9090905@suse.cz> Date: Fri, 28 Aug 2015 16:54:16 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <1440613465-30393-4-git-send-email-emunson@akamai.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2489 Lines: 51 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 > Cc: Michal Hocko > Cc: Vlastimil Babka > Cc: Jonathan Corbet > Cc: "Kirill A. Shutemov" > Cc: linux-kernel@vger.kernel.org > Cc: linux-mm@kvack.org > Cc: linux-api@vger.kernel.org Acked-by: Vlastimil Babka 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. - -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/