Re: non-automated test failure report! :)

[David Holland <dholland-current%netbsd.org@localhost>]

On Wed, Nov 16, 2011 at 06:13:34PM +0000, Eduardo Horvath wrote:
 > > As I said in my previous mail, allocating a page of swap for every
 > > page that *might* get created by the above mechanisms generally
 > > results in allocating vast quantities of swap that are never used.
 > > It's not necessarily a bad thing to have a switch to do this, but in
 > > almost no cases will anyone want to turn it on.
 > 
 > Frankly I disagree.  If you want a robust, stable production system you 
 > want to not overcommit memory.  You only want to turn the checks off if 
 > you don't care about the stability of the machine.  If you want to play on 
 > the wild side then you might want to enable overcommit by a certain 
 > percentage.  But now you don't have that option.  The machine runs fine 
 > until it falls over.

Not really, no. In most ordinary overload cases, it will grind to a
halt swapping long before it actually OOMs. When you've got one or two
processes running away, that's less true... but with a decent OOM
killer those are the processes that get killed, which is exactly what
you'd do if you were sitting at a root prompt responding to the issue.

Like I said, it would perhaps be desirable to have a switch for
pessmistic swap allocation. But there's no real reason to turn it on
in practice.

I used to think the same way you appear to, but then I actually
implemented pessimistic swap allocation once...

 > > As I recall there was a lengthy and fairly high-content discussion of
 > > this on lkml a few years back during the last round of major work on
 > > their OOM-killer. I don't remember the thread title but asking Google
 > > about "linux OOM" will probably turn it up.
 > 
 > Since when have we started taking design advice from linux?

When did I say anything about design advice? I'm talking about the
*problem*, its ramifications, and the risks/downsides of naive
solutions. Last I checked, running out of swap is the same problem in
Linux as in NetBSD. Many people who thought they understood the
problem have been enlightened by reading that particular discussion.

And, though you might think it heresy to say so, their OOM-killer
works a lot better than ours does.

 > Linux is 
 > supposed to be a "desktop OS" so cheapness is more important than 
 > stability.  That's not the decision you want to make for a server. 

Oh, like killing the X server is a good idea on a desktop?

 > Automatically killing random processes is *EVIL*.  Killing fsflush without 
 > restarting it is a bad thing.

The "random" part is where you're going off the rails.

-- 
David A. Holland
dholland%netbsd.org@localhost