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:5.110 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site