Re: [PATCH v5] add MAP_UNLOCKED mmap flag

[Gleb Natapov]

On Thu, Jan 14, 2010 at 04:02:42PM +0900, KOSAKI Motohiro wrote:
> > On Thu, Jan 14, 2010 at 09:31:03AM +0900, KOSAKI Motohiro 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
> > > > in a thread safe manner. 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@xxxxxxxxxx>
> > > > ---
> > > > 
> > > > I get reports that people find this useful, so resending.
> > > 
> > > This description is still wrong. It doesn't describe why this patch is useful.
> > > 
> > I think the text above describes the feature it adds and its use
> > case quite well. Can you elaborate what is missing in your opinion,
> > or suggest alternative text please?
> 
> My point is, introducing mmap new flags need strong and clearly use-case.
> All patch should have good benefit/cost balance. the code can describe the cost,
> but the benefit can be only explained by the patch description.
> 
> I don't think this poor description explained bit benefit rather than cost.
> you should explain why this patch is useful and not just pretty toy.
> 
The benefit is that with this patch I can lock all of my application in
memory except some very big memory areas. My use case is that I want to
run virtual machine in such a way that everything related to machine
emulator is locked into the memory, but guest address space can be
swapped out at will. Guest address space is so huge that it is not
possible to allocated it locked and then unlock. I was very surprised
that current Linux API has no way to do it hence this patch. It may look
like a pretty toy to you until some day you need this and has no way to
do it.

--
			Gleb.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/