Re: [PATCH v3][RFC] add MAP_UNLOCKED mmap flag
From: WANG Cong <hidden>
Date: 2009-10-08 09:09:15
Also in:
linux-mm, lkml
Gleb Natapov [off-list ref] writes:
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 <redacted>
<snip>
quoted hunk
diff --git a/mm/mmap.c b/mm/mmap.c index 73f5e4b..ecc4471 100644 --- a/mm/mmap.c +++ b/mm/mmap.c@@ -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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>