[lkml]   [2000]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 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

> 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?)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:37    [W:0.086 / U:10.500 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site