From owner-freebsd-hackers Fri Jul 16 7:54:46 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from asa.co.uk (mailgate.asa.co.uk [195.173.171.146]) by hub.freebsd.org (Postfix) with ESMTP id C1CB114C01 for ; Fri, 16 Jul 1999 07:54:36 -0700 (PDT) (envelope-from sean.witham@asa.co.uk) Received: from mailgate.asa.co.uk ([195.173.171.146] helo=bentley.asa.co.uk) by asa.co.uk with esmtp (Exim 2.05 #2) id 1159Ib-0005hY-00; Fri, 16 Jul 1999 15:49:17 +0100 Received: from cooch.asa.co.uk ([193.195.233.4] helo=asa.co.uk) by bentley.asa.co.uk with esmtp (Exim 2.05 #3) id 1159Gv-0005hG-00; Fri, 16 Jul 1999 15:47:33 +0100 Message-ID: <378F458F.4BEEB674@asa.co.uk> Date: Fri, 16 Jul 1999 15:45:35 +0100 From: Sean Witham X-Mailer: Mozilla 4.61 [en] (Win95; I) X-Accept-Language: en MIME-Version: 1.0 To: "Daniel C. Sobral" Cc: Garance A Drosihn , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) References: <199907132346.TAA13780@bikini.ihack.net> <378CCB7D.AD8BC57B@newsguy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote: > > It would be nice to have a way to indicate that, a la SIGDANGER. > > Ok, everybody is avoiding this, so I'll comment. Yes, this would be > interesting, and a good implementation will very probably be > committed. *BUT*, this is not as useful as it seems. Since the > correct solution is buy more memory/increase swap (correct solution > for our target markets, anyway), there is little incentive to > implement it. > > So, I think people who can answer the above is thinking like "Well, > it is useful, but it's not useful enough for me to spend my time on > it, and I'm sure as hell don't want to write mini-papers on why it's > not that useful". > For those who wish to develop code for safety related systems that is not good enough. They have to prove that all code can handle the degradation of resources gracefully. Such code relies on guaranteed memory allocations or in the very least warnings of memory shortage and prioritized allocations. So the least important sub-systems die first. --Sean To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message