Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))
To: John Nemeth <>
From: Daniel C. Sobral <>
List: tech-userlevel
Date: 07/15/1999 13:35:01
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)

	"Would you like to go out with me?"
	"I'd love to."
	"Oh, well, n... err... would you?... ahh... huh... what do I do