Olaf writes:
> 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.
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.
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?"
Cheers, Andreas
--
Andreas Dilger \ "If a man ate a pound of pasta and a pound of antipasto,
\ would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/ -- Dogbert
-
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 : Fri Jul 07 2000 - 21:00:21 EST