Messages in this thread | | | Date | Fri, 23 Mar 2001 19:45:26 +0000 | From | Jonathan Morton <> | Subject | Re: [PATCH] Prevent OOM from killing init |
| |
>It would make much sense to make the oom killer >leave not just root processes alone but processes belonging to a UID >lower >then a certain value as well (500). This would be: > >1. Easly managable by the admin. Just let oracle/www and analogous users > have a UID lower then let's say 500.
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/
| |