lkml.org 
[lkml]   [2000]   [Jul]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kernel 2.2.14 OOM killer strikes.
On Fri, 7 Jul 2000, Andreas Dilger wrote:

>> I wonder what happened of the AIX approach: define a new signal (they
>> called it SIGDANGER AFAIK), ignored by default, and send this signal
>> to _all_ processes a few seconds before starting to SIGKILL processes.
>>
>> This moves the policy completely to user space (i.e. The Right Thing).
>> You can either have a daemon listening to this signal and deciding by
>> configuration what and how to kill, or you can implement a handler for
>> graceful exit in suitable applications, or both.
>
>IIRC, programs that have a SIGDANGER handler registered (even if it does
>nothing) are not killed (or at least killed last) - only programs that
>leave ithe default signal handler (which is to ignore SIGDANGER) are
>targets for being killed in an OOM situation. FYI, SIGDANGER=33 on AIX.
>
>Granted that this doesn't handle the case of a malicious user (which I
>don't think can be handled very easily at all), but it WILL handle the
>case of not killing X/init/syslog/getty/sh if they register a SIGDANGER
>handler. On getting such a signal X could attempt to discard window
>backing stores and other non-essential buffers, and xterms could discard
>scrollback buffers, etc. The good news is that it can be implemented
>independently in user-space and in the kernel.

What a FANTASTIC idea! Is there a way of adding such a feature
to apps without source though?

>Now, whether Netscape should register such a handler is up for debate -
>it may very well be the culprit for causing the OOM situation in the
>first place. However, it _could_ also free a lot of memory from its
>internal cache as well.

Yes indeed. Netscape is definitely an OOMish app. It would be
nice to be able to say to netscape "hey, give me back 50Mb of RAM
you potato!" and have netscape actually do it, assuming it isn't
memleaking (yeah right... ;o)

>The real question is "if we hit an OOM situation and manage to free enough
>memory to keep the kernel barely alive, do further malloc/brk requests
>return NULL until we have at least freepages.min, or do we continue to
>over-allocate VM and compound the problem?"

Hmm.. that could be a configureable thing, no? I can see
instances when I'd want one or the other to happen...

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/

\
 
 \ /
  Last update: 2005-03-22 13:57    [W:0.738 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site