lkml.org 
[lkml]   [2000]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: Overcommitable memory??
    Date
    From
    Paul Jakma <paul.jakma@compaq.com> said:
    > On Sun, 19 Mar 2000, David Whysong wrote:
    > > Repeat after me:

    > calm down.. You know you're in too deep when you try to come up with a
    > mantra. :)

    > > You can not solve the OOM problem in user space.
    > > You can not solve the OOM problem without killing processes.

    > well... if you could somehow add swap... (by 'borrowing' from a
    > filesystem).

    Sooner or later that will run out too, and then you are where you started.

    > > Resource limits are not a good solution to the OOM problem.

    > no, limits are not a solution, they are a way of preventing
    > OOM. Different things.

    They are a way of killing processes without declaring OOM (OOM effect
    without OOM :). If they are set up to not overcommit, ever. Rarely done, as
    it is a huge waste. Start over.

    [...]

    > Indeed what suits me for one box, does not suit me for another box.

    > ie on one box i might prefer a fast and loose VM, either because i know
    > the behaviour of the apps i run on it and therefore trust that box not
    > to OOM, or because maybe that box just isn't that important.

    > on another box i might need a more locked down VM with quota's and more
    > extensive accounting of overcommited memory. Possibly because this box
    > runs potentially hostile/unpredictable apps, or else maybe because this
    > box HAS to stay up (ie i could lose my job if it doesn't) and therefore
    > i'm willing to pay in potential VM inefficiency and extra RAM/swap if i
    > can minimise the risk of OOM.

    Very much agree. It would be nice if we were given the alternative, which
    we aren't right now. First question is, who is going to use this? How
    extensively? For what kinds of uses? Next question is, how much does this
    cost, when it is used and when it isn't? How much developer/maintainer/
    tester manpower it consumes has to be counted in here. Both in the kernel
    configuration case "Overcommit memory (Y|n)", in the case where it is
    runtime tunable "Allow tuning memory overcommit at runtime (Y|n)", and a
    fixed alternative.
    --
    Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl
    Departamento de Informatica Fono: +56 32 654431
    Universidad Tecnica Federico Santa Maria +56 32 654239
    Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513

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