Messages in this thread | | | From | "info" <> | Subject | RE: Some questions about linux kernel. | Date | Mon, 13 Mar 2000 02:04:50 -0300 |
| |
PLEASE, REMOVE OF YOUR LIST. i DON´T PROBLEMS WITH YOURS. TM
----- Mensaje original ----- De: Andrea Arcangeli <andrea@suse.de> Para: <riel@nl.linux.org> CC: Adam <adam@eax.com>; Albert D. Cahalan <acahalan@cs.uml.edu>; <linux-kernel@vger.rutgers.edu>; <jmm@computer.org> Enviado: Lunes, 13 de Marzo de 2000 12:14 a.m. Asunto: Re: Some questions about linux kernel.
> On Sun, 12 Mar 2000, Rik van Riel wrote: > > >You might want to take a look at the process selection > >mechanism in my OOM killer patch (http://www.surriel.com/patches/). > > I read the process selection of the oom code in 2.2.15pre12 and it can be > described this way: > > "try _not_ to kill tasks that are been started lots of time ago, > that used lots of CPU resources, that are running > non reniced and that are running as roo or with privilegies" > > The heuristic has _no-way_ to find out which is the hog. This in turn mean > that you can kill several wrong tasks before you finally kill the right > one and so it's useless and worse than what we have now as far I can tell. > > If you hit a feature in a daemon that incidentally causes it to grow at > maximal rate you'll end killing lots of innocents for no good reason. > > Your object is defensive "you try not to kill" something that looks more > important. > > I instead believe that we should be aggressive against the _hog_ instead > of being defensive against some task that may look as non malicious (but > that you don't know to be innocent). > > Once we'll be able to find out which is the hog there will be no need to > look the informations that you are using in your task-selection > algorithm. We know we have to kill the hog, despite of its > euid/priority/lifetime etc... > > The idea I had a few weeks ago to solve the problem and so to find out the > hog (and that I'll experiment in real life 2.3.x soon) is to add a > per-task page fault rate (ala avg_slice). Once we'll know the page fault > rate and the time of the last fault per each process, we'll be almost able > to find out the memory hog without possible mistakes and we won't need > anything else. > > I completly agree with James (I quote him): > > "When you OOM, it's (typically) the case where it's a single process > that's going crazy and being a huge memory hog. Killing other > processes ahead of it won't typically mean very much, as you'll > ^^^^^^ > have to kill more until you finally get to the > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > spiraling-out-of-control memory hog." > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > >> Bottom line is that I don't belive any kind of AI in OMM will do > >> the right job. > > > >So give us a better solution. One that also works for > > The task-selection algorithm have nothing to do with AI. It doesn't know > anything about the past and it is not going to learn anything at runtime. > > Andrea > > > - > 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/ >
- 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/
| |