lkml.org 
[lkml]   [2002]   [Sep]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Killing/balancing processes when overcommited
Giuliano Pochini wrote:
>
> > I still favor an installation file in /etc specifying the order in which
> > things are to be killed. Any alogrithmic assumptions are bound to fail at
> > some point to the dissatisfaction of the installation.
>
> I agree, I don't see any other solution. btw the thing is not
> simple. The oom killer should be able to comply instructions
> like:
>
> if (oom)
> kill netscape if it uses more than 80MB {stdprio 10}
> //sometimes if start sucking memory endlessly
> kill make and its childs if overall they use {stdprio 7}
> more than ...[cpu files memory]
> //ever tried to make -j bzImage on a 64MB box ?
> kill httpd if it's swapping too much {stdprio 3}
> ...

This is hard to setup, and has the some weaknesses:
1. You worry only about apps you _know_. But the guy who got
his netscape or make -j killed will rename his
copies of these apps to something else so your carefully
set up oom killer won't know what is running.
(How much memory is the "mybrowser" app supposed to use?)
Or he'll get another software package that you haven't heard of.

2. Lots and lots of people running netscapes using
only 70M each will still be too much. Think of
a university with xterms and then they all
goes to cnn.com or something for the latest news
about some large event.

Even nice well-behaved apps
is bad when there is unusually many of them.
There may be no particular "offender" to point
a finger at, even for a clueful administrator.
The perfect OOM killer cannot be written - even
a human can't do that job well under all circumstances.

Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

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