That sounds vaguely sensible. However, make it a "much less likely" rather
than an "impossible", otherwise we end up with an unkillable runaway root
process killing everything else in userland.
I'm still in favour of a failing malloc(), and I'm currently reading a bit
of source and docs to figure out where this should be done and why it isn't
done now. So far I've found the overcommit_memory flag, which looks kinda
promising.
>1. Processes with a UID < 100 are immune to OOM killers.
>2. Processes with a UID >= 100 && < 500 are hard for the OOM killer to
>take on.
>3. Processes with a UID >= 500 are easy targets.
As I said above, "immune" can be dangerous. "Extremely hard" would be
better terminology and behaviour. It also helps that the current weighting
in badness() appears to leave getty processes alone, since they don't
consume much and normally have long uptimes - also I believe init would try
to restart them anyway.
--------------------------------------------------------------
from: Jonathan "Chromatix" Morton
mail: chromi@cyberspace.org (not for attachments)
big-mail: chromatix@penguinpowered.com
uni-mail: j.d.morton@lancaster.ac.uk
The key to knowledge is not to rely on people to teach you it.
Get VNC Server for Macintosh from http://www.chromatix.uklinux.net/vnc/
-----BEGIN GEEK CODE BLOCK-----
Version 3.12
GCS$/E/S dpu(!) s:- a20 C+++ UL++ P L+++ E W+ N- o? K? w--- O-- M++$ V? PS
PE- Y+ PGP++ t- 5- X- R !tv b++ DI+++ D G e+ h+ r++ y+(*)
-----END GEEK CODE BLOCK-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/