Date: Wed, 14 Apr 1999 18:07:17 -0500 (CDT) From: Anthony Kimball <alk@pobox.com> To: chuckr@picnic.mat.net Cc: chat@FreeBSD.ORG Subject: Re: swap-related problems Message-ID: <14101.7616.979211.817420@avalon.east> References: <14101.3956.704332.389742@avalon.east> <Pine.BSF.4.10.9904141841070.18456-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoth Chuck Robey on Wed, 14 April: : On Wed, 14 Apr 1999, Anthony Kimball wrote: : : > I disagree. The ability to produce a deterministic execution in : > compliance with the ANSI C standard is a Good Thing too. : : But, as long as you keep resources resonable, that's precisely what you : get under memory overcommit. If you'd see a failure under memory : overcommit, you'd have seen the failure far sooner without memory : overcommit. No, this is incorrect: You are confusing failure modes. A portable, well-written program can recognize that malloc failed and take appropriate steps. : The only other difference is which signal kills your : program. No signal kills a program which handles out-of-memory gracefully, in an environment which support ANSI C semantics. : With memory overcommit, the chances of that program running : without errors, in full ANSI C compliance, are far, far higher. Right. I'm not arguing against memory overcommit. I'm arguing that an application should be able to enforce commit. : In order to stop that behaviour, you'd need to severely penalize all : other programs running on the system. No, you don't need to penalize anyone. Overcommit everyone else. Just let my very special and important program execute according to spec, please. : That'd be a wildly *unpopular* : feature, causing direct harm to most users, as their programs begin : failing much, much more often, due to unnecessary resource starvation. I think this is a bugaboo made of FUD. : Your statement above gives : folks the idea that we are ANSI C non-compliant, and for nearly all : situations, that's false. I disagree, to the degree to which compliance requires determinism. Well-written, portable code should be able to rely upon specified determinism. : It's only in the failure mode, when you are : running more programs than memory allows (including the large : magnification allowed by memory overcommit) that you even can tell a : difference. Compliant failure modes are *very* important. Being able to gracefully handle failure is very important. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14101.7616.979211.817420>