Re: Kernel 2.2.14 OOM killer strikes.

From: Mike A. Harris (mharris@meteng.on.ca)
Date: Sun Jul 09 2000 - 07:15:09 EST


On Sat, 8 Jul 2000, Horst von Brand wrote:

>> >> I'm dreaming up a daemon written in C for speed that:
>> >>
>> >> 1) Reads a config file of legal possible swapfile locations and
>> >> min/max sizes it can use, etc..
>> >> 2) Has configurable high/low watermarks to determine when to
>> >> create new swap space.
>
>It is _much_ easier just to set up said swap space in the first place. No
>kernel mods needed at all.

That entirely depends on the specific system configuration at
hand. I have 96Mb of RAM, and 72Mb of swap. My system RARELY
uses ANY swap space. When it does, it is usually because of
Netscape, and a few other large apps, some of which MIGHT be
memleaking a bit. I never experience any drastic OOM situations
on a regular basis.

Therefore, setting up extra swap permanently won't help me since
my system doesn't require it normally anyway, and it just ties
down disk space. The dynamic swap space provided to me by the
swap daemon (which I am using right now) is EXTREMELY effective
in handling OOM for me - for the case that is most likely to be
the cause - in MY case. The disk space used by these temporary
swap files is on my "/stuff" partition which is my general spare
storage closet with several hundred megs to a few gigs of free
space at any particular time. Therefore, the temp swap files
don't effectively take any space since by definition they are
temporary and ONLY used in emergency situations.

If my system ran out of swap on any sort of regular basis while
running normal apps that were not misbehaving, then what you
suggest makes the absolute best 100% sense than the dynamic swap
solution. It is important to note that this "swapd" solution
isn't just for implementing generally useable swap space here,
but EMERGENCY swap space for situations that are few and far
between, but unexpected - where stealing some disk space in an
emergency will prevent things like X from getting killed, along
with 15-20 apps open with unsaved data, or unbookmarked useful
websites, etc..

There really isn't any noticeable tradeoff or disadvantage.
Under normal conditions, the system will function as it does now,
minus the small footprint of swapd running and checking things
every X number of seconds (configurable).

I would strongly discourage someone from using swapd to implement
their standard swapspace however, since the performance would be
much lower. Best off to have a fixed swap that is as large as
needed under ordinary conditions.

>> In my case, a 'dynswap daemon' would give me a larger window of
>> time in which to 'catch' an OOM situation and use human brain
>> logic to kill processes. I could code the daemon to play a wav
>> file when a swap file is added, another when another swap is
>> added - increasing the 'defcon' number or alarmingness each time,
>> to warn me trouble is near. [...]
>
>Run a (tiny) daemon which periodically checks free space, and warns you
>when running low.

Which is exactly what swapd is doing right now - minus the
warning. I am currently working on adding both pc-speaker and
digital (wav file or au file) warning support to swapd as an
option. It may seem like a hack, but hey - if it works and
someone benefits from it even once, then it is useful albeit
perhaps not the most technically superior solution - which I
doubt will ever exist. So really, it is a 'here and now'
solution that just works - until something perhaps more general
and better comes along with no drawbacks.

TTYL

-- 
Mike A. Harris                                     Linux advocate     
Computer Consultant                                  GNU advocate  
Capslock Consulting                          Open Source advocate

... Our continuing mission: To seek out knowledge of C, to explore strange UNIX commands, and to boldly code where no one has man page 4.

- 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:09 EST