Date: Wed, 14 Apr 1999 17:03:49 -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.3956.704332.389742@avalon.east> References: <14101.711.573218.994126@avalon.east> <Pine.BSF.4.10.9904141714430.18456-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?14101.3956.704332.389742>