From owner-freebsd-hackers Fri Jul 16 3: 8:49 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from cackle.proxima.alt.za (cackle.proxima.alt.za [196.28.218.141]) by hub.freebsd.org (Postfix) with ESMTP id 3E9D514BF6 for ; Fri, 16 Jul 1999 03:08:22 -0700 (PDT) (envelope-from lucio@cackle.proxima.alt.za) Received: (from lucio@localhost) by cackle.proxima.alt.za (8.9.3/8.8.8) id MAA02971; Fri, 16 Jul 1999 12:07:22 +0200 (SAST) Date: Fri, 16 Jul 1999 12:07:21 +0200 From: Lucio De Re To: tech-userlevel@netbsd.org, freebsd-hackers@freebsd.org Subject: Overcommitment - some sanity? Message-ID: <19990716120721.B557@cackle.proxima.alt.za> Reply-To: lucio@proxima.alt.za Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4us Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Let's try to bring this discussion into focus, because it seems worthwhile, despite it having degenerated into a religious war. Let's start from the other end: If *BSD _did_not_have_ the means to overcommit, would one want to add them? I think the obvious answer here is a resounding "Yes", so we should accept Matthew Dillon's perspective as valid on this score.. In general, the point the anti-over-commitment camp keeps raising is always quite correctly shot down by Matthew, if you're not going to run out of swap, then overcommitment can't hurt you. On the other hand, just because there is a hammer solution, that does not mean that all problems are nails. There has to be a mechanism to protect valuable processes from accidental or intentional abuse of resources. Adding more disk space is not always a solution and Matthew himself pointed out that there comes a time when swapping turns to thrashing, at which point too much swap space is a liability not an advantage. If you have _no_ swap space, you're no better off. Personally, I think over-commitment should be switchable on and off at the process level, and there should be an inheritance flag for child processes to do the right thing too. In addition, a global danger signal, probably providing a bit mask that indicates _which_ condition is creating a crisis, some hysteresis as Jason (I seem to recall) requested, and possibly some means of retrieving the identification of the last process to trigger a crisis, should all be available in the overcommit context. Unless I'm reading the debate wrong, SIGDANGER is not required when the system returns NULL if memory is exhausted. Of course, there's nothing that says the semantics of SIGDANGER may include some hysteresis, in which case it could be useful in either context. It may be preferable to combine all these semantics into a single library function (don't ask me, I'm only a user :-) that simplifies the otherwise complex interface. But the bottom layer must be there for those who may want to do some fine tuning. ++L To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message