lkml.org 
[lkml]   [2000]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Kernel 2.2.14 OOM killer strikes.
    On Thu, 6 Jul 2000, Mike A. Harris wrote:

    > On Thu, 6 Jul 2000, Marcelo Tosatti wrote:
    >
    > >> Therefore, since some people WANT OOM killing to be done, and
    > >> others such as myself do NOT want it to be done, could someone in
    > >> the know of doing so, please make it a compile time or run time
    > >> tunable option? I'd like to tell my kernel "If an OOM condition
    > >> occurs, under absolutely *NO* circumstances are you to EVER kill
    > >> a running process".
    > >
    > >If the kernel does not kill some processes (or one process) when the
    > >system is under OOM, probably all the system will lockup because there is
    > >no memory and no more swap space left. Your chance to start a shell and
    > >kill the memory hog is gone.
    >
    > Why can it not work like this: App fills memory. Same app tries
    > to allocate more memory, OOM occurs, app that tried to allocate
    > more memory is killed?
    >
    > Granted, it is possible for app to use all memory and as OOM
    > occurs a DIFFERENT app tries to allocate memory,

    This is the same as using /dev/random to find out which PID to kill. :)

    > but on a desktop box, I believe that that would likely be rarer since
    > it is rarer for OOM on a desktop box in the first place.

    Kill the process which tries to allocate memory under a OOM situation
    is very wrong, and it doesnt matter if it is a desktop or a server box.

    > When OOM, should not the overcommit STOP? In other words, we normally
    > overcommit, but when virtual memory is exhausted completely, any
    > malloc()'s will return NULL to the app? *THAT* would be acceptible to
    > me, if it is possible and no other gotchas result. I could understand
    > it then.
    >
    > >Now _which_ process(es) the kernel should choose to kill is a different
    > >issue.
    >
    > Exactly, and it is not easy to determine - if at all possible.

    Read Rik's oom killer code.

    > >If you do not like the current OOM killer (I think you dont :)), you can
    > >try alternative algorithms, such as Rik van Riel's one. (go to
    > >http://www.surriel.com/patches/ and search for "oom")
    >
    > Well, I do like this suggestion, and might try that out
    > indeed. Unfortunately, OOM is VERY RARE for me.
    > So, one might say I needn't worry because it is such a rarity.
    > Perhaps so, but it irks me that something can actually go _bad_ in
    > Linux and there is no apparent good all winning solution. How about an
    > algorithm that autocreates more swap space from certain preconfigured
    > places while emailing you or wailing sirens that you're in trouble.

    Be my guest (sorry, I could not avoid that :))


    -
    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.022 / U:0.540 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site