From owner-freebsd-chat Wed Apr 14 15: 7:55 1999 Delivered-To: freebsd-chat@freebsd.org Received: from poboxer.pobox.com (unknown [208.149.16.25]) by hub.freebsd.org (Postfix) with ESMTP id 6E4DB15038 for ; Wed, 14 Apr 1999 15:07:51 -0700 (PDT) (envelope-from alk@poboxer.pobox.com) Received: (from alk@localhost) by poboxer.pobox.com (8.9.3/8.9.1) id RAA25608; Wed, 14 Apr 1999 17:03:49 -0500 (CDT) (envelope-from alk) From: Anthony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Apr 1999 17:03:49 -0500 (CDT) X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO 5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed Reply-To: alk@pobox.com To: chuckr@picnic.mat.net Cc: chat@FreeBSD.ORG Subject: Re: swap-related problems References: <14101.711.573218.994126@avalon.east> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14101.3956.704332.389742@avalon.east> Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Quoth Chuck Robey on Wed, 14 April: : : I mean to say by that, if the problem was recognized on a given system : it would happen on that system if memory overcommit *wasn't* the policy. : The difference is that far less programs would be able to run. Nearly : all programs that use lots of malloc, do it sparsely. Stopping memory : overcommit would cause a system to begin returning correct data to : malloc, at the cost of a small fraction of the number of processes being : able to successfully run. Absolutely. Agreed. Overcommit is a good capability, and one which is typically a Good Thing. : One way of looking at this is to focus directly (and only) on malloc, : but that is looking at things with blinders on, and asking for fixes : that would cause egregious harm to nearly all users. I disagree. The ability to produce a deterministic execution in compliance with the ANSI C standard is a Good Thing too. Being able to specify such behaviour when it is required doesn't cause harm to anyone. I suggested one way to do that. mi suggested another -- discriminating the overcommit-overflow case by sending a distinct signal-related event which can be detected by program. That would be a lot more work, though, at the library level, and would be an inferior solution, in my opinion, for several reasons, among them the possibility of losing the overcommit kill lottery. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message