[lkml]   [2000]   [Jul]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    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
    > > 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
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:57    [W:0.023 / U:39.728 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site