Re: Kernel 2.2.14 OOM killer strikes.

From: Marcelo Tosatti (marcelo@conectiva.com.br)
Date: Thu Jul 06 2000 - 17:27:49 EST


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/



This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:20 EST