: I don't like the idea of killing off tasks that request resources that
: are not presently available. I think they should sleep (interruptable)
: until resouces are available -if ever. This allows the user to determine
: if he/she wants a particular task to continue.
Hi Richard,
I agree that there are probably good actions that an educated sysadmin
or a well-written controlling tool in user space can take; and I don't
want to suggest killing a job is the only protection Linux should take
against memory overload. [*]
However, as a last resort if all virtual memory is full (including swap)
and other user-space utilities for handling that might not even get
scheduled (perhaps since they don't get the necessary stack page or so),
the kernel should either reboot or make a clean cut and kill the most
serious offender to protect the survival of the rest of the OS.
I do not at all mind if my machine kills an oversized job. I do mind
however if the oversized job kills my machine while I'm devising that
wonderful new algorithm ;).
Claus
* Possible solutions before the last resort
[1] Sacrificial 'kill me first' jobs.
[2] User-defined jobs (not) to be killed.
[3] Freeze the job list after boot and don't kill these.
[4] A memory pool for large batch jobs.
[5] A memory limit per user.
[6] A swap threshold where all large jobs are SIGTSTP'd.
[7] A distinction between allocation of large and small units.
[8] Freezable and restartable jobs.
[9] System load adaptive jobs.
[10] A special init mode which the system enters
(freeze everything, remove all init 3 jobs, wait for remote login).
...
-- claus.fischer@intel.com Intel Corporation SC12-205 ... not speaking phone +1-408-765-6808 2200 Mission College Blvd. for Intel fax +1-408-765-9322 Santa Clara, CA 95052-8119
- 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/