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 reallystrange is going on and there's not much hope for rescueingit ;)

They are niced because the user thinks them a bit lessimportant. 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 socoarse that this makes little sense. Also, a nice+20process is often more "important" than the nice+4 cronjob ... ;)

> 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 changesso fast that it means almost nothing. Furthermore, once a processhas used a lot of CPU time, killing it means you're potentiallythrowing 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.