Date: Wed, 14 Jul 1999 15:58:23 -0400 From: Michael Richardson <mcr@sandelman.ottawa.on.ca> To: jnemeth@victoria.tc.ca (John Nemeth) Cc: freebsd-hackers@freebsd.org, tech-userlevel@netbsd.org Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2)) Message-ID: <199907141958.PAA02088@pzero.sandelman.ottawa.on.ca> In-Reply-To: Your message of "Wed, 14 Jul 1999 10:53:27 PDT." <199907141753.KAA02096@vtn1.victoria.tc.ca>
index | next in thread | previous in thread | raw e-mail
>>>>> "John" == John Nemeth <jnemeth@victoria.tc.ca> writes:
John> On one system I administrate, the largest process is typically
John> rpc.nisd (the NIS+ server daemon). Killing that process would be a
John> bad thing (TM). You're talking about killing random processes.
John> This is no way to run a system. It is not possible for any
John> arbitrary decision to always hit the correct process. That is a
John> decision that must be made by a competent admin. This is the
John> biggest argument against overcommit: there is no way to gracefully
John> recover from an out of memory situation, and that makes for an
John> unreliable system.
No, I don't agree.
This is a biggest argument against solving the overcommit situation with
SIGKILL. I have no problem with overcommit as a concept, I have a problem
with being unable to keep my possibly big processes (X, rpc.nisd,
etc. depending on cicumstances) from being victims.
] Train travel features AC outlets with no take-off restrictions| firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199907141958.PAA02088>