Messages in this thread | | | Date | Sat, 8 Jul 2000 06:46:31 -0400 (EDT) | From | "Mike A. Harris" <> | Subject | Re: OOM in 2.2.14 |
| |
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 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/
| |