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 advocateI'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/
This archive was generated by hypermail 2b29 : Fri Jul 07 2000 - 21:00:19 EST