Messages in this thread |  | | Date | Sun, 20 Aug 2000 16:08:58 +0100 (BST) | From | James Sutherland <> | Subject | Re: Out of memory? |
| |
On Sun, 20 Aug 2000, Michael Rothwell wrote: > David Ford wrote: > > > The kernel does try to kill off programs when it runs out of memory but > > unless it picks the memory pig, then that program will probably immediately > > grab any memory the kernel just freed. > > Killing, for instance, kswapd. On my machine last week, the kernel > started killing processes. Its first choice was kswapd, and then it went > on to my window manager and about 10 other programs. > > It was pretty retarded.
That probably wasn't the brightest choice to make...
There are patches out there which make this behaviour a little more sensible, though - e.g. kill the process which has grabbed the most memory recently, to kill off things which go into a leaking loop (Netscape does this a lot...).
> I know Linux overcommits memory and has no way of knowing who the real > overallocator culprit is, but wouldn't some resource accounting be good?
A nice daemon to keep an eye on things memory-wise would make a big difference; someone wrote one a few months ago during the nuclear flamewar over "overcommit". The most common problem of this sort is probably an app "going rogue", and grabbing lots of RAM; you couldn't react fast enough to this, but a nice -20 daemon probably could. Failing that, an "intelligent" kernel-side killer can still reduce the fallout when the system goes bang...
> Or perhaps a tunable or compile-time option to turn off overcommits?
That would just make matters a bit worse: you'd run out of memory a bit sooner, but still end up with things dying more or less at random. What is really needed is proper resource accounting - which is currently an optional patch out there somewhere. (Try searching the l-k archives for "beancounter", IIRC?)
James.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |