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?"