All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gleb Natapov <gleb@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-api@vger.kernel.org
Subject: Re: [PATCH][RFC] add MAP_UNLOCKED mmap flag
Date: Tue, 6 Oct 2009 13:00:00 +0200	[thread overview]
Message-ID: <20091006110000.GJ9832@redhat.com> (raw)
In-Reply-To: <200910061249.53030.arnd@arndb.de>

On Tue, Oct 06, 2009 at 12:49:52PM +0200, Arnd Bergmann wrote:
> On Tuesday 06 October 2009, Gleb Natapov wrote:
> > 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>
> > diff --git a/include/asm-generic/mman.h b/include/asm-generic/mman.h
> > index 32c8bd6..0ab4c74 100644
> > --- a/include/asm-generic/mman.h
> > +++ b/include/asm-generic/mman.h
> > @@ -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_UNLOKED    0x80000         /* pages are unlocked */
> >  
> >  #define MCL_CURRENT    1               /* lock all current mappings */
> >  #define MCL_FUTURE     2               /* lock all future mappings */
> 
> Not all architectures use asm-generic/mman.h, so you have to change
> the other architectures separately if you add a flag.
> 
Ah, good to know. Thanks.

--
			Gleb.

--
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>

WARNING: multiple messages have this Message-ID (diff)
From: Gleb Natapov <gleb@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	linux-api@vger.kernel.org
Subject: Re: [PATCH][RFC] add MAP_UNLOCKED mmap flag
Date: Tue, 6 Oct 2009 13:00:00 +0200	[thread overview]
Message-ID: <20091006110000.GJ9832@redhat.com> (raw)
In-Reply-To: <200910061249.53030.arnd@arndb.de>

On Tue, Oct 06, 2009 at 12:49:52PM +0200, Arnd Bergmann wrote:
> On Tuesday 06 October 2009, Gleb Natapov wrote:
> > 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>
> > diff --git a/include/asm-generic/mman.h b/include/asm-generic/mman.h
> > index 32c8bd6..0ab4c74 100644
> > --- a/include/asm-generic/mman.h
> > +++ b/include/asm-generic/mman.h
> > @@ -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_UNLOKED    0x80000         /* pages are unlocked */
> >  
> >  #define MCL_CURRENT    1               /* lock all current mappings */
> >  #define MCL_FUTURE     2               /* lock all future mappings */
> 
> Not all architectures use asm-generic/mman.h, so you have to change
> the other architectures separately if you add a flag.
> 
Ah, good to know. Thanks.

--
			Gleb.

  reply	other threads:[~2009-10-06 11:00 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-06  9:51 [PATCH][RFC] add MAP_UNLOCKED mmap flag Gleb Natapov
2009-10-06  9:51 ` Gleb Natapov
2009-10-06 10:09 ` Frederik Deweerdt
2009-10-06 10:09   ` Frederik Deweerdt
2009-10-06 10:11 ` KOSAKI Motohiro
2009-10-06 10:11   ` KOSAKI Motohiro
2009-10-06 10:21   ` Gleb Natapov
2009-10-06 10:21     ` Gleb Natapov
2009-10-06 10:27     ` KOSAKI Motohiro
2009-10-06 10:27       ` KOSAKI Motohiro
2009-10-06 10:33       ` Gleb Natapov
2009-10-06 10:33         ` Gleb Natapov
2009-10-06 12:10         ` KOSAKI Motohiro
2009-10-06 12:10           ` KOSAKI Motohiro
2009-10-06 12:16           ` Gleb Natapov
2009-10-06 12:16             ` Gleb Natapov
2009-10-06 13:50             ` Peter Zijlstra
2009-10-06 13:50               ` Peter Zijlstra
2009-10-06 14:06               ` Gleb Natapov
2009-10-06 14:06                 ` Gleb Natapov
2009-10-07 18:50             ` Olivier Galibert
2009-10-07 18:50               ` Olivier Galibert
2009-10-07 18:59               ` Gleb Natapov
2009-10-07 18:59                 ` Gleb Natapov
2009-10-07 20:10                 ` Olivier Galibert
2009-10-07 20:10                   ` Olivier Galibert
2009-10-07 20:47                   ` Gleb Natapov
2009-10-07 20:47                     ` Gleb Natapov
2009-10-06 10:49 ` Arnd Bergmann
2009-10-06 11:00   ` Gleb Natapov [this message]
2009-10-06 11:00     ` Gleb Natapov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20091006110000.GJ9832@redhat.com \
    --to=gleb@redhat.com \
    --cc=arnd@arndb.de \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.