From owner-freebsd-hackers Wed Jul 14 11:24: 5 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from xroads.vthrc.uq.edu.au (xroads.vthrc.uq.edu.au [130.102.4.16]) by hub.freebsd.org (Postfix) with ESMTP id C198715421 for ; Wed, 14 Jul 1999 11:23:58 -0700 (PDT) (envelope-from D.Thomas@vthrc.uq.edu.au) Received: (from fwtk@localhost) by xroads.vthrc.uq.edu.au (8.8.6/8.8.6) id EAA01072; Thu, 15 Jul 1999 04:22:48 +1000 (EST) Received: from d-thomas-mac.vthrc.uq.edu.au(130.102.4.80) by xroads.vthrc.uq.edu.au via smap (V1.3) id sma001070; Thu Jul 15 04:22:31 1999 X-Sender: Vthomas@130.102.4.16 Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Thu, 15 Jul 1999 04:22:31 +1000 To: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org From: D.Thomas@vthrc.uq.edu.au (Danny Thomas) Subject: Re: Swap overcommit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Ted Faber >For every strategy there's a counterstrategy. exactly: the disappointing thing about this whole thread is there's been little discussion of implementing a (tunable) policy how to handle the situation when resource shortage materialises. Overcommitment can be useful, maybe even for most people... >Killing the biggest is simple to implement and usually right. ... but some people don't want that policy, at least on some of their systems. Does FreeBSD offer alternatives? Is so, they've been conspicuously absent from discussion, which might have taken things into a more productive vein. What do other over-committing systems offer? Danny Thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message