Date: Thu, 15 Jul 1999 13:35:01 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: John Nemeth <jnemeth@victoria.tc.ca> Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Message-ID: <378D64F5.5AA2CC5F@newsguy.com> References: <199907141753.KAA02096@vtn1.victoria.tc.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
John Nemeth wrote: > > On one system I administrate, the largest process is typically > rpc.nisd (the NIS+ server daemon). Killing that process would be a > bad thing (TM). You're talking about killing random processes. This > is no way to run a system. It is not possible for any arbitrary > decision to always hit the correct process. That is a decision that > must be made by a competent admin. This is the biggest argument > against overcommit: there is no way to gracefully recover from an > out of memory situation, and that makes for an unreliable system. If you run out of memory, it is either a misconfigured system, or a runaway program. If a program is runaway, then: 1) It is larger than your typical rpc.nisd. 2) You cannot tell the system a priori to kill it, because you don't know about it (or else, you wouldn't be running it in first place). A system running in overcommit assumes that you have it correctly configured so it will *not* run out of memory under normal conditions. This happens to be the same assumption Unix does. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org "Would you like to go out with me?" "I'd love to." "Oh, well, n... err... would you?... ahh... huh... what do I do next?" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?378D64F5.5AA2CC5F>