Messages in this thread | | | Date | Thu, 6 Jul 2000 19:27:49 -0300 (BRT) | From | Marcelo Tosatti <> | Subject | Re: 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/
| |