Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))
To: Ben Rosengart <>
From: Michael Richardson <>
List: tech-userlevel
Date: 07/14/1999 16:01:20
>>>>> "Ben" == Ben Rosengart <> writes:
    Ben> On Wed, 14 Jul 1999, 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.

    Ben> $DEITY on a pogo stick, how many times do we have to hear the same
    Ben> hypothetical argument?

    Ben> Tell me, Mr. Nemeth, has this ever happened to you?  Have you ever
    Ben> come *close*?

  Uh, since we don't run overcommit, the answer is specifically *NO*.

  We have never had lack of swap space randomly kill one of our processes.
This is good, and this is the way we want to keep it. 

  I have had it happen on other systems. (Solaris, AIX) It was very
mystifying to diagnose. Sure, the systems were misconfigured for what we
were trying to do, but if I wanted build a custom system for every
application.... well... I'd be running NT.

] Train travel features AC outlets with no take-off restrictions|  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [