From owner-freebsd-chat Fri Apr 16 12:50: 4 1999 Delivered-To: freebsd-chat@freebsd.org Received: from peach.ocn.ne.jp (peach.ocn.ne.jp [210.145.254.87]) by hub.freebsd.org (Postfix) with ESMTP id 8B2FA159D5 for ; Fri, 16 Apr 1999 12:49:24 -0700 (PDT) (envelope-from dcs@newsguy.com) Received: from newsguy.com by peach.ocn.ne.jp (8.9.1a/OCN) id EAA27900; Sat, 17 Apr 1999 04:46:58 +0900 (JST) Message-ID: <37179347.D9D0FFEA@newsguy.com> Date: Sat, 17 Apr 1999 04:45:11 +0900 From: "Daniel C. Sobral" X-Mailer: Mozilla 4.51 [en] (Win98; I) X-Accept-Language: pt-BR,ja MIME-Version: 1.0 To: David Schwartz Cc: chat@FreeBSD.ORG Subject: Re: swap-related problems References: <000001be8833$f9dd1d80$021d85d1@whenever.youwant.to> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org David Schwartz wrote: > > There might be a demand for, for example, separate swap for critical and > non-critical processes. Or there may be a wish to reserve a certain amount > of swap just for critical processes, or to require overcommittment to exceed > a certain amount before 'critical' processes have their allocations fail. > > This is a tuning question. It's easily possible to err in either direction. > > The point is, however, that a well-behaved process can't behave well > without adequate feedback. And a fully-overcommitting kernel generally can't > provide that feedback. A never-overcommitting kernel can, but unfortunately, > that simply requires too much swap. Surely a reasonable compromise can be > struck. Sure. We call it limiting a process/user datasize. This solution is not more complicated than any other solution short of full pre-allocation, even if you do not believe so. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Well, Windows works, using a loose definition of 'works'..." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message