Messages in this thread | | | Date | Thu, 6 Jul 2000 19:31:15 -0400 (EDT) | From | "Mike A. Harris" <> | Subject | Re: Kernel 2.2.14 OOM killer strikes. |
| |
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, 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. 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.
>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. Heck, give a daemon your credit card number and have it order more RAM online when resources get low. I guess we'd need a speedy way of delivering it then though, and an automated way of installing it in a hot swapable manner... ;o)
Any takers?
Take care, and thanks for the suggestion. TTYL
-- Mike A. Harris Linux advocate Computer Consultant GNU advocate Capslock Consulting Open Source advocate
I've overclocked my keyboard interface. It's quite messy dipping my hands into the mineral oil, but *MAN* is my keyboard ever fast now! - Anonymous Coward
- 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/
| |