Messages in this thread | | | Date | Sat, 8 Jul 2000 04:52:14 -0400 (EDT) | From | "Mike A. Harris" <> | Subject | Re: Kernel 2.2.14 OOM killer strikes. |
| |
On Fri, 7 Jul 2000, Andreas Dilger wrote:
>Date: Fri, 7 Jul 2000 10:30:02 -0600 (MDT) >From: Andreas Dilger <adilger@turbolabs.com> >To: mharris@meteng.on.ca >Cc: Linux kernel development list <linux-kernel@vger.rutgers.edu> >Subject: Re: Kernel 2.2.14 OOM killer strikes. > >Mike Harris writes: >> I'm dreaming up a daemon written in C for speed that: >> [snip] >> 3) Can monitor memory/swap usage on the fly every X number of >> seconds (configurable) ... and then creates a swap >> file or files as quickly as possible (with nice -20) > >Then you will be out of memory, and your disk will be full in the likely >event that you have an out-of-control program using up all of your memory.
Yes, that could happen indeed. What I'm saying though is that, with the above idea, the daemon would have high priority, and thus the highest chance of completing its job of creating swap. Since the thresholds would be configurable, I could set it so that if 60% of swap space is used, add another 100Mb. I could tell it to do this to a max of 3 times for example. This does NOT solve the problem of OOM'ing. It does however do one of 2 things:
1) It postpones the problem, giving me a chance to fire off top and look into the problem, *POSSIBLY* being able to manually kill an errant process, or slow it down, or even save data that may be at stake..
2) It might end up adding enough VM that happens to be enough for whatever was wanting so much memory. Remember, not every OOM condition is caused by memleaking apps. In my case, it was an app wanting 150Mb of RAM. If I'd had a daemon add extra swap, it would have succeeded, and no OOM would have occured.
One important thing to note here, is that I'm trying to solve _MY_ problem here specifically, and not come up with a general catch all solution, nor one that is intended to be included in the general kernel.
I dislike the idea of dynamic swap in a sense of how it is done in Windows, because it is slow and inefficient, however in Linux, where one can control things much more, I can see myself liking the fact that I've got an extra 'chance' to _possibly_ stop a problem from occuring. The disk space of course is no problem because it wouldn't be disk space that is missed, and would be temporary for the duration of the problem. The daemon can also monitor disk space usage on the partition's it is configured to be allowed to use, and can attempt to avoid a device full condition.
This is a TOTALLY *HACK* solution, and nothing more... if it works, and saves any work I'm working on, that cover the hours spent implementing it, then it is worth it - regardless of it's technical purity IMHO. Other people may come up with ideas to add to it to make the idea even more useful as well...
Well, thanks for the comments everyone.. I'm getting more ideas to work with, the more posts I read. Keep 'em coming!
Take care, 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/
| |