Subject: Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))
To: John Nemeth <>
From: Michael Richardson <>
List: tech-userlevel
Date: 07/14/1999 15:58:23
>>>>> "John" == John Nemeth <> 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[
] |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [