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 20:36 +0300, Al Boldi wrote:
> 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?

yes. Using only 1 page shared is already overcommitting because in
principle each user can cause a COW on that page and cause a memory
allocation for it in the future. (just like "traditional" overcommit can
cause a pagefault with an allocation)


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

then I think you're misunderstanding how the linux VM works


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

but it's a worthwhile gamble to not need GOBBLES of memory you're not
using 99.9999999999999% of the time

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

swap==ram is not really relevant; you'll need a LOT more to cover the
shared maps...


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