According to woods@most.weird.com (Greg A. Woods) :
> 
> The system should be more robust than relying on an external operator to
> intervene in these kinds of situations.
> 
I agree entirely, but it would be nice, when robustness isn't 
available, to permit human intervention.  There are lots of instances 
where the decision making is just too complex to throw mere instruction 
cycles at it.

> I know that robust programming isn't always the easiest thing to do, but
> if the system itself isn't robust then all the programming efforts in
> the world of user-land robustness are not going to help!  ;-)
> 
Again, I agree.  But robustness can come from only two sources: 
greater simplicity or additional complexity.  NetBSD appealed to me 
most because of its (relative) simplicity, whereas we _may_ have to 
sacrifice some of this simplicity to additional robustness.  It is a 
compromise I find hard to swallow.

> > > But if the killer process does its job well, this is not necessary..
> > > 
> > I think merely suspending any further process loading until swap space 
> > returns below the low-water mark would be less intrusive, but that's 
> > merely a policy that can be tuned to local conditions.
> 
> Of course merely suspending fork et al would be less intrusive, but
> unless you go around knocking on some doors to at least say "We're in
> trouble here!  Something's got to be done!" then you can't assume that
> the user land will notice anything at all or do anything positive.  You
> don't have to have a smoking gun in hand when you knock on those doors,
> but sometimes it helps....  (How's that for an analogy that's apropos
> for world politics this week!  ;-)
> 
I presume I didn't make myself clear: I am in favour of Ian Dall's 
suggestion _and_ I believe that we can go back to a situation where 
overcommittment of memory is an option, not the default.  I think Ian's 
suggestion addresses some of the symptoms, where the second option (I 
forget who brought it up) needs greater consideration.

> Remember -- the kernel has *already* over-commited VM space.  What else
> can it do when suddenly it's in a COW situation with nowhere to copy to?
> 
> Right now all it does is "have a cow" and everything usually comes to a
> grinding halt.  (For all you non-farmers: cow's are very stubborn *and*
> very stupid animals -- you have to be really smart and sneaky to get
> them to do what you want without raising a rukus.)  (For all you pedant
> etymologists, no, I don't know if that's the true origin of that
> phrase.)
> 
Ian suggests that the system may still have kittens, but in a better 
controlled environment, this while we find a bigger stick to convince 
the cow to behave itself.

++L