[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.154 / U:12.984 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site