Messages in this thread | | | From | WANG Cong <> | Subject | Re: [PATCH v3][RFC] add MAP_UNLOCKED mmap flag | Date | Thu, 08 Oct 2009 17:10:35 +0800 |
| |
Gleb Natapov <gleb@redhat.com> 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 <gleb@redhat.com>
<snip>
> 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.
| |