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 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