Messages in this thread | | | Date | Wed, 15 Mar 2000 15:32:03 +0000 (GMT) | From | James Sutherland <> | Subject | Re: Some questions about linux kernel. |
| |
On Wed, 15 Mar 2000, Sean Hunter wrote:
> On Tue, Mar 14, 2000 at 02:40:27PM -0300, Rik van Riel wrote: > > On Mon, 13 Mar 2000, Peter T. Breuer wrote: > > > > > > For the time being, though, the simple "kill the most likely suspect" > > > > patch should be a pretty good approximation. > > > > > > Nope. It isn't. It's unacceptable in practice. > > > > > > I run labs. The lab machines have to have defenses against > > > _themselves_. > > > > > > Even so, I get reports every couple of days from machines that > > > have obviously killed themselves. > > > > You don't run the OOM killer. You haven't tried it. > > Yet you want to judge it without any knowledge about > > it... > > Could I just stress one point which Rik and others keep making and > people keep ignoring? The in-kernel OOM killer is not (meant to be) a > finely-honed user-customisable tool. Its a very effective thing when > the memory state is completely dire. It should never run, and when it > does, its the last-ditch defence and if it wasn't there your system > would die anyway.
Precisely - complaining that you would rather have your box die uncontrollably, because you are sitting there holding its hand 24x7 to watch the lights go out, is hardly productive. If you ARE monitoring it closely enough to fix things, you would fix them long before the disaster recovery OOM routine cuts in!
> If you want something clever and/or subtle, you need to run it in > userland _as well_ as the in-kernel oom killer, and if the userland > thingy does its job, the in-kernel killer should never need to run.
Plenty of people have CPU leak detectors, which will renice (and later kill) processes which take more than a certain length of time. This is an absolute godsend for stopping things like Netscape which have a horrible habit of going into a busy loop, eating 100% of CPU time until killed.
Something similar to implement crude per-user quotas could be useful - just check periodically how much RAM each user is using, and tell them if they exceed their quota (a "soft" quota) - would probably address the "normal" low-memory situation (exploding Netscapes etc.)
> I think Rik gets a ridiculous amount of flak from people who can't be > bothered to try his patch or listen to what he and others are trying > to do, but want to mouth off anyway.
Agreed. Complaining about Rik's patch "killing my poor defenceless process, which had blown up for a good reason - I really DID want it to exhaust all my swapspace and then kill itself, not be killed by the big bad nasty kernel!" is ridiculous. The processes it kills will almost always be killed because they are causing serious problems for the system. A process only gets killed in this way to protect overall system integrity, not as a matter of routine housekeeping.
James.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |