lkml.org 
[lkml]   [2000]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectOOM 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/

\
 
 \ /
  Last update: 2005-03-22 12:41    [W:0.199 / U:1.416 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site