[lkml]   [2000]   [Oct]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC] New ideas for the OOM handler
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

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