Re: non-automated test failure report! :)

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

On Wed, Nov 16, 2011 at 08:34:08PM +0000, Michael van Elst wrote:
 > >Not really, no. In most ordinary overload cases, it will grind to a
 > >halt swapping long before it actually OOMs.
 > 
 > I see OOMs a lot on Linux and hardly any of these follow
 > heavy swapping. Mostly it is a heavily loaded system and
 > something suddenly touching non-allocated memory
 > it never should have been granted.

Blah... that I haven't seen actually, but I don't have or use any
heavily loaded Linux systems any more.

 > >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.
 > 
 > Stability is a reason. But in Linux not even disabling
 > overcommittment and having swap larger than RAM helps to
 > eliminate the OOM killer.

That seems odd. With overcommit turned off it shouldn't ever OOM.

 >> The "random" part is where you're going off the rails.
 > 
 > It is still "random" to some degree, used to be worse.

Ours is not; if you have a runaway process it's just about always the
one that gets killed. Once in a while it kills the X server instead
though, because the X server is a large process that sometimes eats a
lot of memory. However, it almost invariably follows up on this by
killing syslogd, which is pretty poor.

(As best I can tell this is because it logs that it's going to do the
kill before or as it does it; this wakes up syslogd, syslogd goes into
the kernel to handle the message, tries to allocate kernel memory,
fails, and then becomes another victim.)

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