Re: overcommit verses MAP_NORESERVE

[Nicholas Miell <nmiell@comcast.net>]

On Sun, 2005-08-07 at 12:49 +0100, Alan Cox wrote:
> On Sad, 2005-08-06 at 20:52 -0700, Nicholas Miell wrote:
> > Why does overcommit in mode 2 (OVERCOMMIT_NEVER) explicitly force
> > MAP_NORESERVE mappings to reserve memory?
> > 
> > My understanding is that MAP_NORESERVE is a way for apps to state that
> > they are aware that the memory allocated may not exist and that they
> > might get a SIGSEGV and that's OK with them.
> 
> Because a MAP_NORESERVE space that is filled with pages might cause
> insufficient memory to be left available for another object that is not
> MAP_NORESERVE.
> 
> You are right it could be improved but that would require someone
> writing code that forcibly reclaimed MAP_NORESERVE objects when we were
> close to out of memory.  At the moment nobody has done this, but nothing
> is stopping someone having a go.

I don't think you can forcibly reclaim MAP_NORESERVE objects (I'm
assuming you mean completely throwing away dirty pages).

MAP_NORESERVE isn't standardized, so all we can go by is what everybody
else does (and what makes the most sense).

Based on the Linux and Solaris man pages (none of FreeBSD, Irix, HP-UX,
or AIX implement anything similar), I think calls to mmap() with
MAP_NORESERVE should always succeed (regardless of memory conditions,
not other errors) and individual writes to unallocated pages in a
MAP_NORESERVE region should either allocate a new page if possible or
send a SIGSEGV without triggering the OOM killer.

-- 
Nicholas Miell <nmiell@comcast.net>

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