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: <200512311702.20525.a1426z@gawab.com>
References: <200512302306.28667.a1426z@gawab.com>
	 <200512310759.02962.a1426z@gawab.com>
	 <20051231073817.GZ15993@alpha.home.local>
	 <200512311702.20525.a1426z@gawab.com>
Content-Type: text/plain
Date: Sat, 31 Dec 2005 15:26:18 +0100
Message-Id: <1136039178.2901.25.camel@laptopd505.fenrus.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 829
Lines: 18

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.


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