Subject: Re: [PATCH] strict VM overcommit accounting for 2.4.32/2.4.33-pre1
From: Arjan van de Ven <arjan@infradead.org>
To: Al Boldi <a1426z@gawab.com>
Cc: Willy Tarreau <willy@w.ods.org>, Alan Cox <alan@lxorguk.ukuu.org.uk>,
       barryn@pobox.com, linux-kernel@vger.kernel.org
In-Reply-To: <200512312036.01351.a1426z@gawab.com>
References: <200512302306.28667.a1426z@gawab.com>
	 <200512311702.20525.a1426z@gawab.com>
	 <1136039178.2901.25.camel@laptopd505.fenrus.org>
	 <200512312036.01351.a1426z@gawab.com>
Content-Type: text/plain
Date: Sun, 01 Jan 2006 10:12:33 +0100
Message-Id: <1136106754.17830.4.camel@laptopd505.fenrus.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2108
Lines: 49

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/