Messages in this thread |  | | Date | Fri, 6 Oct 2000 17:31:11 -0300 (BRST) | From | Rik van Riel <> | Subject | Re: [PATCH] VM fix for 2.4.0-test9 & OOM handler |
| |
On Fri, 6 Oct 2000, Byron Stanoszek wrote: > On Fri, 6 Oct 2000, Rik van Riel wrote: > > > 3. add the out of memory killer, which has been tuned with > > -test9 to be ran at exactly the right moment; process > > selection: "principle of least surprise" <== OOM handling > > In the OOM killer, shouldn't there be a check for PID 1 just to > enforce that INIT will not be the victim? Sure its total_vm > might be small, but if there was a memory leak in the kernel > somewhere, it might eventually become the target. I suppose, if > it ever were to become the victim, your system wouldn't be too > usable anyway...
Indeed, if init is chosen for some reason, something really strange is going on and there's not much hope for rescueing it ;)
> Can you give me your rationale for selecting 'nice' processes as > being badder?
They are niced because the user thinks them a bit less important. This includes stuff like cron jobs that _just_ push a system over the edge ...
> Do you think it would be a good idea to scale the amount of > badness according to how nice the process is (a nice value of 20 > could get the full *2, otherwise a smaller multiplier)?
I've thought about this, but the algorithms used are so coarse that this makes little sense. Also, a nice+20 process is often more "important" than the nice+4 cron job ... ;)
> How about using the current process priority level instead of > nicety. If a process was deprioritized (or auto-niced) because > it was starting to eat up CPU time, AND its memory is abnormally > high, then should that be our #1 victim?
Not really. In the first place, the dynamic priority changes so fast that it means almost nothing. Furthermore, once a process has used a lot of CPU time, killing it means you're potentially throwing away a lot of useful work that's been done.
(same for a process which has been running a long time)
> We also don't want to kill things like benchmarks either, but > hopefully they wouldn't start eating up more than the available > system memory.
*grin*
regards,
Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
- 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/
|  |