Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
On 07/10/2015 06:19 PM, Eric B Munson wrote: On Fri, 10 Jul 2015, Jonathan Corbet wrote: On Thu, 9 Jul 2015 14:46:35 -0400 Eric B Munson emun...@akamai.com wrote: One other question...if I call mlock2(MLOCK_ONFAULT) on a range that already has resident pages, I believe that those pages will not be locked until they are reclaimed and faulted back in again, right? I suspect that could be surprising to users. That is the case. I am looking into what it would take to find only the present pages in a range and lock them, if that is the behavior that is preferred I can include it in the updated series. For whatever my $0.02 is worth, I think that should be done. Otherwise the mlock2() interface is essentially nondeterministic; you'll never really know if a specific page is locked or not. Thanks, jon Okay, I likely won't have the new set out today then. This change is more invasive. IIUC, I need an equivalent to __get_user_page() skips pages which are not present instead of faulting in and the call chain to get to it. Unless there is an easier way that I am missing. IIRC having page PageMlocked and put on unevictable list isn't necessary to prevent it from being reclaimed. It's just to prevent it from being scanned for reclaim in the first place. When attempting to unmap the page, vma flags are still checked, see the code in try_to_unmap_one(). You should probably extend the checks to your new VM_ flag as it is done for VM_LOCKED and then you shouldn't need to walk the pages to mlock them (although it would probably still be better for the accounting accuracy). Eric ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
On Fri, 10 Jul 2015, Jonathan Corbet wrote: On Thu, 9 Jul 2015 14:46:35 -0400 Eric B Munson emun...@akamai.com wrote: One other question...if I call mlock2(MLOCK_ONFAULT) on a range that already has resident pages, I believe that those pages will not be locked until they are reclaimed and faulted back in again, right? I suspect that could be surprising to users. That is the case. I am looking into what it would take to find only the present pages in a range and lock them, if that is the behavior that is preferred I can include it in the updated series. For whatever my $0.02 is worth, I think that should be done. Otherwise the mlock2() interface is essentially nondeterministic; you'll never really know if a specific page is locked or not. Thanks, jon Okay, I likely won't have the new set out today then. This change is more invasive. IIUC, I need an equivalent to __get_user_page() skips pages which are not present instead of faulting in and the call chain to get to it. Unless there is an easier way that I am missing. Eric signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
On Thu, 9 Jul 2015 14:46:35 -0400 Eric B Munson emun...@akamai.com wrote: One other question...if I call mlock2(MLOCK_ONFAULT) on a range that already has resident pages, I believe that those pages will not be locked until they are reclaimed and faulted back in again, right? I suspect that could be surprising to users. That is the case. I am looking into what it would take to find only the present pages in a range and lock them, if that is the behavior that is preferred I can include it in the updated series. For whatever my $0.02 is worth, I think that should be done. Otherwise the mlock2() interface is essentially nondeterministic; you'll never really know if a specific page is locked or not. Thanks, jon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
On Wed, 08 Jul 2015, Jonathan Corbet wrote: On Wed, 8 Jul 2015 16:34:56 -0400 Eric B Munson emun...@akamai.com wrote: Quick, possibly dumb question: I've been beating my head against these for a little bit, and I can't figure out what's supposed to happen in this case: mlock2(addr, len, MLOCK_ONFAULT); munlock2(addr, len, MLOCK_LOCKED); It looks to me like it will clear VM_LOCKED without actually unlocking any pages. Is that the intended result? This is not quite right, what happens when you call munlock2(addr, len, MLOCK_LOCKED); is we call apply_vma_flags(addr, len, VM_LOCKED, false). From your explanation, it looks like what I said *was* right...what I was missing was the fact that VM_LOCKED isn't set in the first place. So that call would be a no-op, clearing a flag that's already cleared. Sorry, I misread the original. You are correct with the addition that the call to munlock2(MLOCK_LOCKED) is a noop in this case. One other question...if I call mlock2(MLOCK_ONFAULT) on a range that already has resident pages, I believe that those pages will not be locked until they are reclaimed and faulted back in again, right? I suspect that could be surprising to users. That is the case. I am looking into what it would take to find only the present pages in a range and lock them, if that is the behavior that is preferred I can include it in the updated series. Thanks, jon signature.asc Description: Digital signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
On Tue, 7 Jul 2015 13:03:41 -0400 Eric B Munson emun...@akamai.com wrote: 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. This can be done area at a time via the mlock2(MLOCK_ONFAULT) or the mlockall(MCL_ONFAULT) system calls. These calls can be undone via munlock2(MLOCK_ONFAULT) or munlockall2(MCL_ONFAULT). Quick, possibly dumb question: I've been beating my head against these for a little bit, and I can't figure out what's supposed to happen in this case: mlock2(addr, len, MLOCK_ONFAULT); munlock2(addr, len, MLOCK_LOCKED); It looks to me like it will clear VM_LOCKED without actually unlocking any pages. Is that the intended result? Thanks, jon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
On Wed, 8 Jul 2015 16:34:56 -0400 Eric B Munson emun...@akamai.com wrote: Quick, possibly dumb question: I've been beating my head against these for a little bit, and I can't figure out what's supposed to happen in this case: mlock2(addr, len, MLOCK_ONFAULT); munlock2(addr, len, MLOCK_LOCKED); It looks to me like it will clear VM_LOCKED without actually unlocking any pages. Is that the intended result? This is not quite right, what happens when you call munlock2(addr, len, MLOCK_LOCKED); is we call apply_vma_flags(addr, len, VM_LOCKED, false). From your explanation, it looks like what I said *was* right...what I was missing was the fact that VM_LOCKED isn't set in the first place. So that call would be a no-op, clearing a flag that's already cleared. One other question...if I call mlock2(MLOCK_ONFAULT) on a range that already has resident pages, I believe that those pages will not be locked until they are reclaimed and faulted back in again, right? I suspect that could be surprising to users. Thanks, jon ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
On Wed, 08 Jul 2015, Jonathan Corbet wrote:
On Tue, 7 Jul 2015 13:03:41 -0400
Eric B Munson emun...@akamai.com wrote:
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. This can be done area at a time via the
mlock2(MLOCK_ONFAULT) or the mlockall(MCL_ONFAULT) system calls. These
calls can be undone via munlock2(MLOCK_ONFAULT) or
munlockall2(MCL_ONFAULT).
Quick, possibly dumb question: I've been beating my head against these for
a little bit, and I can't figure out what's supposed to happen in this
case:
mlock2(addr, len, MLOCK_ONFAULT);
munlock2(addr, len, MLOCK_LOCKED);
It looks to me like it will clear VM_LOCKED without actually unlocking any
pages. Is that the intended result?
This is not quite right, what happens when you call munlock2(addr, len,
MLOCK_LOCKED); is we call apply_vma_flags(addr, len, VM_LOCKED, false).
The false argument means that we intend to clear the specified flags.
Here is the relevant snippet:
...
newflags = vma-vm_flags;
if (add_flags) {
newflags = ~(VM_LOCKED | VM_LOCKONFAULT);
newflags |= flags;
} else {
newflags = ~flags;
}
...
Note that when we are adding flags, we first clear both VM_LOCKED and
VM_LOCKONFAULT. This was done to match the behavior found in
mlockall(). When we are remove flags, we simply clear the specified
flag(s).
So in your example the state of the VMAs covered by addr and len would
remain unchanged.
It sounds like apply_vma_flags() needs a comment covering this topic, I
will include that in the set I am working on now.
Eric
signature.asc
Description: Digital signature
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH V3 3/5] mm: mlock: Introduce VM_LOCKONFAULT and add mlock flags to enable it
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. This can be done area at a time via the mlock2(MLOCK_ONFAULT) or the mlockall(MCL_ONFAULT) system calls. These calls can be undone via munlock2(MLOCK_ONFAULT) or munlockall2(MCL_ONFAULT). To keep accounting checks out of the page fault path, users are billed for the entire mapping lock as if MLOCK_LOCKED was used. Signed-off-by: Eric B Munson emun...@akamai.com Cc: Michal Hocko mho...@suse.cz Cc: Vlastimil Babka vba...@suse.cz Cc: linux-al...@vger.kernel.org Cc: linux-ker...@vger.kernel.org Cc: linux-m...@linux-mips.org Cc: linux-par...@vger.kernel.org Cc: linuxppc-dev@lists.ozlabs.org Cc: sparcli...@vger.kernel.org Cc: linux-xte...@linux-xtensa.org Cc: linux...@kvack.org Cc: linux-a...@vger.kernel.org Cc: linux-...@vger.kernel.org --- arch/alpha/include/uapi/asm/mman.h | 2 + arch/mips/include/uapi/asm/mman.h| 2 + arch/parisc/include/uapi/asm/mman.h | 2 + arch/powerpc/include/uapi/asm/mman.h | 2 + arch/sparc/include/uapi/asm/mman.h | 2 + arch/tile/include/uapi/asm/mman.h| 3 ++ arch/xtensa/include/uapi/asm/mman.h | 2 + fs/proc/task_mmu.c | 1 + include/linux/mm.h | 1 + include/uapi/asm-generic/mman.h | 2 + mm/mlock.c | 72 ++-- mm/mmap.c| 4 +- mm/swap.c| 3 +- 13 files changed, 75 insertions(+), 23 deletions(-) diff --git a/arch/alpha/include/uapi/asm/mman.h b/arch/alpha/include/uapi/asm/mman.h index ec72436..77ae8db 100644 --- a/arch/alpha/include/uapi/asm/mman.h +++ b/arch/alpha/include/uapi/asm/mman.h @@ -37,8 +37,10 @@ #define MCL_CURRENT 8192 /* lock all currently mapped pages */ #define MCL_FUTURE 16384 /* lock all additions to address space */ +#define MCL_ONFAULT32768 /* lock all pages that are faulted in */ #define MLOCK_LOCKED 0x01/* Lock and populate the specified range */ +#define MLOCK_ONFAULT 0x02/* Lock pages in range after they are faulted in, do not prefault */ #define MADV_NORMAL0 /* no further special treatment */ #define MADV_RANDOM1 /* expect random page references */ diff --git a/arch/mips/include/uapi/asm/mman.h b/arch/mips/include/uapi/asm/mman.h index 67c1cdf..71ed81d 100644 --- a/arch/mips/include/uapi/asm/mman.h +++ b/arch/mips/include/uapi/asm/mman.h @@ -61,11 +61,13 @@ */ #define MCL_CURRENT1 /* lock all current mappings */ #define MCL_FUTURE 2 /* lock all future mappings */ +#define MCL_ONFAULT4 /* lock all pages that are faulted in */ /* * Flags for mlock */ #define MLOCK_LOCKED 0x01/* Lock and populate the specified range */ +#define MLOCK_ONFAULT 0x02/* Lock pages in range after they are faulted in, do not prefault */ #define MADV_NORMAL0 /* no further special treatment */ #define MADV_RANDOM1 /* expect random page references */ diff --git a/arch/parisc/include/uapi/asm/mman.h b/arch/parisc/include/uapi/asm/mman.h index daab994..c0871ce 100644 --- a/arch/parisc/include/uapi/asm/mman.h +++ b/arch/parisc/include/uapi/asm/mman.h @@ -31,8 +31,10 @@ #define MCL_CURRENT1 /* lock all current mappings */ #define MCL_FUTURE 2 /* lock all future mappings */ +#define MCL_ONFAULT4 /* lock all pages that are faulted in */ #define MLOCK_LOCKED 0x01/* Lock and populate the specified range */ +#define MLOCK_ONFAULT 0x02/* Lock pages in range after they are faulted in, do not prefault */ #define MADV_NORMAL 0 /* no further special treatment */ #define MADV_RANDOM 1 /* expect random page references */ diff --git a/arch/powerpc/include/uapi/asm/mman.h b/arch/powerpc/include/uapi/asm/mman.h index 189e85f..f93f7eb 100644 --- a/arch/powerpc/include/uapi/asm/mman.h +++ b/arch/powerpc/include/uapi/asm/mman.h @@ -22,8 +22,10 @@ #define MCL_CURRENT 0x2000 /* lock all currently mapped pages */ #define MCL_FUTURE 0x4000 /* lock all additions to address space */ +#define MCL_ONFAULT0x8000 /* lock all pages that are faulted in */ #define MLOCK_LOCKED 0x01
