lkml.org 
[lkml]   [2005]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: oom killer gone nuts
    On Thu, Jan 20, 2005 at 12:00:34PM -0200, Marcelo Tosatti wrote:
    > On Thu, Jan 20, 2005 at 02:15:56PM +0100, Andries Brouwer wrote:

    > > Yes, the fact that the oom-killer exists is a serious problem.
    > > People work on trying to tune it, instead of just removing it.
    > >
    > > I am getting reports that also in overcommit mode 2 (no overcommit,
    > > no oom-killer ever needed) processes are killed by the oom-killer
    > > (on 2.6.10).
    >
    > Hi Andries,
    >
    > There is a user requirement for overcommit mode, you know.
    >
    > Saying "hey, there's no more overcommit mode in future v2.6 releases, you
    > run out of memory and get -ENOMEM" is not really an option is it?
    >
    > You propose to remove the OOM killer and do what? Lockup solid?

    Right now we have three overcommit modes.
    They are specified by:
    0: overcommit, but keep it reasonable (the current default)
    1: overcommit, always say yes
    2: keep track of all our obligations, do not overcommit

    So, one has the right to expect that no OOM situation can occur
    in overcommit mode 2. But in 2.6.10 it can. That is a bug.
    The conclusion must be that bookkeeping is done incorrectly.
    Perhaps also mode 0 is affected by that same bug.


    Now you ask what I propose. There is no hurry worrying about that -
    the first thing should be to fix the bookkeeping problem.


    But assume that fixed. Then everybody can run in mode 2 and never
    have any problems. That is what I do.

    Yes, you say, but that is an inefficient use of memory. Perhaps.
    That is the price I am willing to pay for the guarantee that my
    processes are not killed at some random moment.

    But if someone else does not do anything of importance and doesnt
    care if his processes die at arbitrary moments if only things go
    as fast as possible and use as much of his precious memory as possible,
    then also for him overcommit mode 2 can be useful.
    It is accompanied by the variable overcommit_ratio R - the amount
    of memory that can be used is Swap + Memory*(R/100). Here R can be
    larger than 100, so in overcommit mode 2 one can specify very precisely
    what amount of overcommitment is considered acceptable.


    Very few people run overcommit mode 2, and lots of things are
    badly tested. It cannot become the default today.
    But I would like to see it the default at some future moment.

    Andries
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 14:09    [W:0.023 / U:154.768 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site