On Sat, 8 Jul 2000, David Bronaugh wrote:
>When talking about slow mem leaks and such, I agree with Mike
>A. Harris. There should be a userland daemon to track free
>memory and, if it falls below a critical level, add more swap.
Keep in mind that I'm not suggesting this as a general solution
for everyone though.. just to suit my personal OOM problem. This
solution of dynamic swap is NOT good enough for all OOM problems
in all situations. It assumes one has disk space in abundance
with which to steal from, and it assumes that a user is sitting
at the machine to notice something going awry. Such a daemon
could send an email, play a wav file, or do something else to
alert the user of a potential upcoming OOM situation.
This is ok for a hacker workstation, but certainly NOT for joe
blow, or a Windows user. It also is no good for busy servers,
and other unattended machines. Reason being that if apps require
more than the given VM, there is a good chance it is a true
runaway app, and the dynamic swap won't help at all. It will
just delay the inevitable.
My solution IMHO is only good if the app causing the OOM - isn't
out of hand, but rather just being hungry with memory... dynamic
swap might just increase the VM pool large enough for the app to
do its deed without causing the system to OOM. Most of my OOM
cases have been ones fitting this description I believe.
The other case where it is good is if a true runaway app goes in
an infinite loop stealing memory, or if a memleaker gradually
uses up VM. This buys an interactive user some time to try and
manually decide how to fix the problem before it goes too
far. The audio alarm would be a cool benefit indeed.
This solution however, is a userland issue - a potentially useful
application (daemon), not really a kernel solution. I think it
will be a decent solution to my problem though.
>This seems like a sensible solution, as it is quick and, as it
>is not in the kernel, it is easy to disable or enable without
>rebooting (god forbid! :). You can't have the solution in the
>kernel simply because it's not kosher for the kernel to do such
>things (sorry if i'm saying things other people already know).
>
>Anyways, I'll end my little rant. I'd be interested to hear comments on
>this.
Well, I pretty much agree with all that. I wouldn't dream of
sticking anything like this in-kernel. I'll leave the in-kernel
OOM stuff to someone who sleeps with printouts of the vm code
beside them in bed..
;o)
Take care all,
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 : Sat Jul 15 2000 - 21:00:08 EST