lkml.org 
[lkml]   [2000]   [Mar]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: Some questions about linux kernel.
Date
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/

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