Messages in this thread |  | | Date | Mon, 23 Oct 2000 16:53:52 -0700 (PDT) | From | Joe <> | Subject | OOM and my .02 cents |
| |
Hi all, I read this week in kernelnotes about the OOM killer and thought I'd share a few thoughts that I had on the subject. I know I am maybe considered a 'nobody' here so my opinion may count very little, but this makes sense to me as a user so I though I'd throw in my .02 cents. If you like it use if not delete this email and forget about it.
1) If it does not already do this it should probably start with warnings like printk statements. (I'll hope it does).
2) There should probably be a way to configure OOM (if there is not already). I.E either a % or in bytes before we say we are out of memory. This could default to something like 10% of the remaining memory or 1% or whatever. This would probably have 2 values. Start warning messages at 10% start killing at 5% or something, or one value could be based on the other value. I'd prefer a percent basis, cause you wont know how much memory a system has till the sytem boots and if someone puts in kill at 32Meg and the system has 16 well, you do the math. This could possiblly even be configurable through the /proc interface or a compile time thing or both.
With these two bits of info it would be fairly easy to write a user space program that would scan the sys logs for the OOM warnings and pop up a message in X saying that something needs to die. This kind of functionality could be added into X and then if X sees a warning in the sys logs about OOM then X can refuse to start another program. This is assuming the X group wanted to do so. Personally if they did not I'd do it in Gtk or Xaw or something myself.
3) This should probably be capable of being compiled as a module, so that if someone decided to add functionality to it for X it would not make the kernel (bzImage) grow exponentially. The reason I say this is that if you look at the trends in Linux then you'll realize that everything is moving towards X. Even IBM's via voice has a GUI. Do you really know where Linux will have morphed to in 10 years? It's always better to be flexable now then to find yourself screwed in the future.
Even if this were a seperate patch it could possiblly in theory be done.
Fact is when that code gets on someones system you don't know what there needs are or what they'll do with it.
If you look at windows it pops up a message when you try to start a program and you don't have the memory for it, someone or some distribution could do this for Linux if they were so inclined. You know there are some people out there that are into that kind of thing.
4) Lastly, if this is truely an OOM killer it's hueristics, should probably just see which progam(s) are taking up the most memory, and which one(s) were started last. The last program that is taking up the most memory should then be killed. Why? Chances are that the last program that is started that is taking over the most memory is probably your problem. init is # 1 in my process table and the first 5 are kernel related dameons. X starts after that even when xdm/gdm are running. If X had a memory leak and was killed by the OOM most window mangers will catch this and save a users settings. If anyone looses data it is really there fault for not saving every 5 minutes anyway.
Lastly the other option rather than killing the program is to restart the program.
just my .02 cents.
__________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |