Date: Wed, 14 Apr 1999 18:49:24 -0400 (EDT) From: Chuck Robey <chuckr@picnic.mat.net> To: Anthony Kimball <alk@pobox.com> Cc: chat@FreeBSD.ORG Subject: Re: swap-related problems Message-ID: <Pine.BSF.4.10.9904141841070.18456-100000@picnic.mat.net> In-Reply-To: <14101.3956.704332.389742@avalon.east>
next in thread | previous in thread | raw e-mail | index | archive | help
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. The only other difference is which signal kills your program. With memory overcommit, the chances of that program running without errors, in full ANSI C compliance, are far, far higher. In order to stop that behaviour, you'd need to severely penalize all other programs running on the system. 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 could there might be one or two special users who would disagree, but it would be something on the order of much less than 1% of users (if they understood what was really at stake). Your statement above gives folks the idea that we are ANSI C non-compliant, and for nearly all situations, that's false. 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. 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. > > > ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- 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?Pine.BSF.4.10.9904141841070.18456-100000>