Re: [RFC] New ideas for the OOM handler

From: David Feuer (
Date: Fri Oct 13 2000 - 02:19:44 EST

Long-running processes are not always important. If I'm running an RC5
cracker or similar program, I want that killed right after the fork
bomb. While it's generally bad to interrupt simulations etc., it is
perfectly fine to do so if they are properly designed so they save their
state as they go along. If I were writing a really long simulation, I'd
make sure it was interruptible, and that there were provisions for
automatically restarting it when it died.

Note: On long-running, unsupervised systems, it is sometimes better to
reboot than to do an OOM kill, unless the system is set up to be able to
automatically restart critical programs that die. For instance, if a mail
server gets OOM because of a mem leak in sendmail, it's better to crash and
reboot than to kill sendmail, unless it's auto-restarted.

This message has been brought to you by the letter alpha and the number pi.
David Feuer

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to Please read the FAQ at

This archive was generated by hypermail 2b29 : Sun Oct 15 2000 - 21:00:24 EST