add MAP_UNLOCKED mmap flag

RFC PATCH Superseded Gleb Natapov 2 participants 4 messages Oct 6, 2009 – Oct 8, 2009

Subsystems (10)

Memory management PowerPC MIPS Generic include/asm header files +6 more subsystems

lore

Share & tools

lore

Gleb Natapov

author

2009-10-06 19:03 UTC #0 lore raw

RFC PATCH v3 1/1 add MAP_UNLOCKED mmap flag

If application does mlockall(MCL_FUTURE) it is no longer possible to mmap file bigger than main memory or allocate big area of anonymous memory. Sometimes it is desirable to lock everything related to program execution into memory, but still be able to mmap big file or allocate huge amount of memory and allow OS to swap them on demand. MAP_UNLOCKED allows to do that.

Signed-off-by Gleb Natapov <[email protected]>

---

v1->v2
- adding new flag to all archs
- fixing typo
v2->v3
- one more typo fix

arch/alpha/include/asm/mman.h +1 -0

index 99c56d4..cfc51ac 100644
@@ -30,6 +30,7 @@
 #define MAP_NONBLOCK	0x40000		/* do not block on IO */
 #define MAP_STACK	0x80000		/* give out an address that is best suited for process/thread stacks */
 #define MAP_HUGETLB	0x100000	/* create a huge page mapping */
+#define MAP_UNLOCKED	0x200000	/* force page unlocking */
 
 #define MS_ASYNC	1		/* sync memory asynchronously */
 #define MS_SYNC		2		/* synchronous memory sync */

arch/mips/include/asm/mman.h +1 -0

index a2250f3..c161e27 100644
@@ -48,6 +48,7 @@
 #define MAP_NONBLOCK	0x20000		/* do not block on IO */
 #define MAP_STACK	0x40000		/* give out an address that is best suited for process/thread stacks */
 #define MAP_HUGETLB	0x80000		/* create a huge page mapping */
+#define MAP_UNLOCKED	0x100000	/* force page unlocking */
 
 /*
  * Flags for msync

arch/parisc/include/asm/mman.h +1 -0

index 9749c8a..4e8b9bf 100644
@@ -24,6 +24,7 @@
 #define MAP_NONBLOCK	0x20000		/* do not block on IO */
 #define MAP_STACK	0x40000		/* give out an address that is best suited for process/thread stacks */
 #define MAP_HUGETLB	0x80000		/* create a huge page mapping */
+#define MAP_UNLOCKED	0x100000	/* force page unlocking */
 
 #define MS_SYNC		1		/* synchronous memory sync */
 #define MS_ASYNC	2		/* sync memory asynchronously */

arch/powerpc/include/asm/mman.h +1 -0

index d4a7f64..7d33f01 100644
@@ -27,6 +27,7 @@
 #define MAP_NONBLOCK	0x10000		/* do not block on IO */
 #define MAP_STACK	0x20000		/* give out an address that is best suited for process/thread stacks */
 #define MAP_HUGETLB	0x40000		/* create a huge page mapping */
+#define MAP_UNLOCKED	0x80000		/* force page unlocking */
 
 #ifdef __KERNEL__
 #ifdef CONFIG_PPC64

arch/sparc/include/asm/mman.h +1 -0

index c3029ad..f80d203 100644
@@ -22,6 +22,7 @@
 #define MAP_NONBLOCK	0x10000		/* do not block on IO */
 #define MAP_STACK	0x20000		/* give out an address that is best suited for process/thread stacks */
 #define MAP_HUGETLB	0x40000		/* create a huge page mapping */
+#define MAP_UNLOCKED	0x80000		/* force page unlocking */
 
 #ifdef __KERNEL__
 #ifndef __ASSEMBLY__

arch/xtensa/include/asm/mman.h +1 -0

index fca4db4..c62bcd8 100644
@@ -55,6 +55,7 @@
 #define MAP_NONBLOCK	0x20000		/* do not block on IO */
 #define MAP_STACK	0x40000		/* give out an address that is best suited for process/thread stacks */
 #define MAP_HUGETLB	0x80000		/* create a huge page mapping */
+#define MAP_UNLOCKED	0x100000	/* force page unlocking */
 
 /*
  * Flags for msync

include/asm-generic/mman.h +1 -0

index 32c8bd6..59e0f29 100644
@@ -12,6 +12,7 @@
 #define MAP_NONBLOCK	0x10000		/* do not block on IO */
 #define MAP_STACK	0x20000		/* give out an address that is best suited for process/thread stacks */
 #define MAP_HUGETLB	0x40000		/* create a huge page mapping */
+#define MAP_UNLOCKED	0x80000         /* force page unlocking */
 
 #define MCL_CURRENT	1		/* lock all current mappings */
 #define MCL_FUTURE	2		/* lock all future mappings */

mm/mmap.c +3 -0

index 73f5e4b..ecc4471 100644
@@ -985,6 +985,9 @@ unsigned long do_mmap_pgoff(struct file *file, unsigned long addr,
 		if (!can_do_mlock())
 			return -EPERM;
 
+        if (flags & MAP_UNLOCKED)
+                vm_flags &= ~VM_LOCKED;
+
 	/* mlock MCL_FUTURE? */
 	if (vm_flags & VM_LOCKED) {
 		unsigned long locked, lock_limit;

--
Gleb.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

WANG Cong

2009-10-08 09:08 UTC #1 lore raw

Quoted 8 lines · Gleb Natapov

If application does mlockall(MCL_FUTURE) it is no longer possible to mmap file bigger than main memory or allocate big area of anonymous memory. Sometimes it is desirable to lock everything related to program execution into memory, but still be able to mmap big file or allocate huge amount of memory and allow OS to swap them on demand. MAP_UNLOCKED allows to do that.
Signed-off-by Gleb Natapov <[email protected]>

<snip>

Quoted 5 lines

mm/mmap.c +0 -0

index 73f5e4b..ecc4471 100644

mm/mmap.c unsigned long do_mmap_pgoff(struct file *file, unsigned long addr, · line 993

Quoted 9 lines

mm/mmap.c +3 -0

@@ -985,6 +985,9 @@ unsigned long do_mmap_pgoff(struct file *file, unsigned long addr,
 		if (!can_do_mlock())
 			return -EPERM;
 
+        if (flags & MAP_UNLOCKED)
+                vm_flags &= ~VM_LOCKED;
+
 	/* mlock MCL_FUTURE? */
 	if (vm_flags & VM_LOCKED) {
 		unsigned long locked, lock_limit;

So, if I read it correctly, it is perfectly legal to set both MAP_LOCKED and MAP_UNLOCKED at the same time? While the behavior is still same as only setting MAP_UNLOCKED.

Is this what we expect?

Regards.

Gleb Natapov

author

2009-10-08 09:16 UTC #2 lore raw

Quoted 32 lines · WANG Cong

Quoted 8 lines · Gleb Natapov
If application does mlockall(MCL_FUTURE) it is no longer possible to mmap file bigger than main memory or allocate big area of anonymous memory. Sometimes it is desirable to lock everything related to program execution into memory, but still be able to mmap big file or allocate huge amount of memory and allow OS to swap them on demand. MAP_UNLOCKED allows to do that.
Signed-off-by Gleb Natapov <[email protected]>
<snip>
Quoted 5 lines
mm/mmap.c +0 -0
index 73f5e4b..ecc4471 100644
mm/mmap.c unsigned long do_mmap_pgoff(struct file *file, unsigned long addr, · line 993
Quoted 9 lines
mm/mmap.c +3 -0
@@ -985,6 +985,9 @@ unsigned long do_mmap_pgoff(struct file *file, unsigned long addr,
 		if (!can_do_mlock())
 			return -EPERM;
 
+        if (flags & MAP_UNLOCKED)
+                vm_flags &= ~VM_LOCKED;
+
 	/* mlock MCL_FUTURE? */
 	if (vm_flags & VM_LOCKED) {
 		unsigned long locked, lock_limit;
So, if I read it correctly, it is perfectly legal to set both MAP_LOCKED and MAP_UNLOCKED at the same time? While the behavior is still same as only setting MAP_UNLOCKED.

Quoted 2 lines

Is this what we expect?

This is what code does currently. Should we return EINVAL in this case?

--
Gleb.

WANG Cong

2009-10-08 09:35 UTC #3 lore raw

Quoted 33 lines · Gleb Natapov

Quoted 32 lines · WANG Cong
Quoted 8 lines · Gleb Natapov
If application does mlockall(MCL_FUTURE) it is no longer possible to mmap file bigger than main memory or allocate big area of anonymous memory. Sometimes it is desirable to lock everything related to program execution into memory, but still be able to mmap big file or allocate huge amount of memory and allow OS to swap them on demand. MAP_UNLOCKED allows to do that.
Signed-off-by Gleb Natapov <[email protected]>
<snip>
Quoted 5 lines
mm/mmap.c +0 -0
index 73f5e4b..ecc4471 100644
mm/mmap.c unsigned long do_mmap_pgoff(struct file *file, unsigned long addr, · line 993
Quoted 9 lines
mm/mmap.c +3 -0
@@ -985,6 +985,9 @@ unsigned long do_mmap_pgoff(struct file *file, unsigned long addr,
 		if (!can_do_mlock())
 			return -EPERM;
 
+        if (flags & MAP_UNLOCKED)
+                vm_flags &= ~VM_LOCKED;
+
 	/* mlock MCL_FUTURE? */
 	if (vm_flags & VM_LOCKED) {
 		unsigned long locked, lock_limit;
So, if I read it correctly, it is perfectly legal to set both MAP_LOCKED and MAP_UNLOCKED at the same time? While the behavior is still same as only setting MAP_UNLOCKED.

Quoted 4 lines

Quoted 2 lines
Is this what we expect?
This is what code does currently. Should we return EINVAL in this case?

I suppose to get an EINVAL.