Re: non-automated test failure report! :)

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

On Wed, Nov 16, 2011 at 11:22:54AM +0700, Robert Elz wrote:
 >   | On Tue, Nov 15, 2011 at 05:51:20PM +0000, Eduardo Horvath wrote:
 >   |  > allow the kernel to return errors through the system call interface 
 >   |  > instead of just killing off processes.
 > 
 >   | maybe even to be able to warn
 >   | about or deny running the job that's likely to put the system over.
 > 
 > That's exactly what "return errors through the system call interface"
 > means - deny fork(), brk(), or mmap() if they go beyond the limit.

That's fine if those are what go beyond the limit. And this is what
happens if the process goes past its limits. But when the system is
completely out of swap, this isn't usually what causes it. More often
it's something that has no error path, like allocating an additional
stack page or copying a copy-on-write page, or providing a real page
when writing to a previously zerofilled region.

At this point, if you have no more pages left, there isn't anything
you can do besides start throwing thunderbolts. All you can really do
is be more or less smart about where you throw them, or take
additional steps to try to avoid running into the situation at all,
which is what I was suggesting.

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.

 > That's what the system used to be like, and it actually worked

Yes, in the days before copy-on-write fork. :-P

It's not as simple as that any more.

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.

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