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

[Al Boldi <a1426z@gawab.com>]

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.

Are you implying shared maps are implemented by way of overcommitting?

Really, overcommit is an add-on feature like swapping, only overcommit is 
free because it's a lier.  So removing an add-on feature should not affect 
the underlying system in any way, such as shared mappings or swapping.

It should be possible to allow swapping to handle all memory requests 
exceeding physical RAM.  OverCommit should be a tuning option for those who 
like to live on the edge, because it really is a gamble.

In the case where swap = physical RAM and overcommit_ratio = 0, the kernel is 
in effect hiding the fact that it is overcommitting.

Can you see the overhead involved here?

Thanks for your input!

--
Al