Messages in this thread | | | Date | Fri, 16 Jul 1999 22:25:39 +0200 (MEST) | From | Bernd Paysan <> | Subject | Re: OOM |
| |
On Fri, 16 Jul 1999, Claus Fischer wrote:
> Inheriting points from the parent process doesn't really work very well. > You could make an extremely small program, exec() it (which would > presumably zero the score, or would you want to keep the score > >from the large shell?),
Yes, since even a large shell should - when running for some time - have a low score. And after all, if you *use* a large shell (emacs? ;-), it's entirely your fault that the memory is so tight :-).
> Evanescating scores by a certain factor per second just means that a > malicious hog has to be careful to wait for a certain time before > starting.
Hm, one point is: if a hog allocates memory slowly, you have time to react. After all, there are a lot of non-malicious programs that allocate memory slowly over time, and you are really pissed if they get killed.
> Also it's not good if two processes allocate the same amount of memory > shortly after one another, but only the second gets malus points since > swapping only started when the second one allocated.
This is just a sort of conservative capitalistic/aristocratic algorithm. If all cheap resources are occupied, allocating new resources becomes more expensive. The idea is to keep the setting in a sane state by killing newcomers. People don't want to get their two-week simulation killed, therefore Rik's algorithm takes total cpu usage (processes with more computing power invested are worth more) and runtime into account.
I think Rik's algorithm is good enough and has the enormous advantage of being cost-free in normal operation (*and* it has been tested). I'll take his weighting algorithm (size/(sqrt(cpu_time)*sqrt(sqrt(run_time)))), but add my warning shot, and convert it to a more recent kernel (2.3.10). Too bad that we don't have a free signal for SIGMEM at hand ;-).
Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
- 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/
| |