Date: Mon, 26 Feb 2001 16:53:23 -0300 (BRST) From: Rik van Riel <riel@conectiva.com.br> To: Matt Dillon <dillon@earth.backplane.com> Cc: Peter Seebach <seebs@plethora.net>, <freebsd-hackers@FreeBSD.ORG> Subject: Re: Setting memory allocators for library functions. Message-ID: <Pine.LNX.4.33.0102261650340.5502-100000@duckman.distro.conectiva> In-Reply-To: <200102260709.f1Q79fq30005@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 25 Feb 2001, Matt Dillon wrote: > The problem is a whole lot more complex then you think. Dealing with > overcommit is not simply counting mapped pages, there are all sorts > of issues involved. But the biggest gotcha is that putting in > overcommit protection will not actually save your system from > dying a terrible death. It in fact makes it *more* likely that the > system will die a horrible death, Indeed, but since a lot of the non-overcommit fans will not believe this, why not let them find out by themselves when they write a patch for it? And maybe, just maybe, they'll succeed in getting their idea of non-overcommit working with a patch which doesn't change dozens of places in the kernel and doesn't add any measurable overhead. (a while ago we had our yearly discussion on linux-kernel about this, after some time somebody showed up with code to do overcommit ... and, of course, the conclusion that it wouldn't work since he got to understand the problem better while writing the code ;)) regards, Rik -- Linux MM bugzilla: http://linux-mm.org/bugzilla.shtml Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://www.conectiva.com/ http://distro.conectiva.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.33.0102261650340.5502-100000>