Re: [PATCH] strict VM overcommit accounting for 2.4.32/2.4.33-pre1

[Arjan van de Ven <arjan@infradead.org>]

On Sat, 2005-12-31 at 15:58 +0100, Willy Tarreau wrote:
> On Sat, Dec 31, 2005 at 03:26:18PM +0100, Arjan van de Ven wrote:
> > On Sat, 2005-12-31 at 17:02 +0300, Al Boldi wrote:
> > 
> > > Shouldn't it be possible to disable overcommit completely, thus giving kswapd 
> > > a break from running wild trying to find something to swap/page, which is 
> > > the reason why the system gets unstable going over 95% in your example.
> > 
> > shared mappings make this impractical. To disable overcommit completely,
> > each process would need to account for all its own shared libraries, eg
> > each process gets glibc added etc. You'll find that on any
> > non-extremely-stripped system you then end up with much more memory
> > needed than you have ram.
> 
> Arjan, is this true even for read-only mappings such as shared libs ?

shared libs aren't read only! they have all the relocations applied for
example. (the fact that glibc mprotects it read only again afterwards
doesn't change things.. part of the memory is already written to). and
mprotect can be called again.... what would mprotect need to do if it's
asked to make memory writable and the overcommit says "no space" ....


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