Messages in this thread | | | Date | Wed, 8 Feb 2006 10:57:14 -0800 | From | Paul Jackson <> | Subject | Re: Terminate process that fails on a constrained allocation |
| |
> No it only disables the oom killer for constrained allocations.
But on many big numa systems, the way they are administered, that affectively disables the oom killer.
> F.e. a sysadmin may mistakenly start a process allocating too much memory > in a cpuset. The OOM killer will then start randomly shooting other > processes one of which may be a critical process.. Ouch.
That same exact claim could be made to justify a patch that removed mm/oom_kill.c entirely. And the same exact claim could be made, dropping the "in a cpuset" phrase, on an UMA desktop PC.
The basic premise of the oom killer is that, instead of blowing off the caller, who might innocently have asked for one page too many after some other hog used up all the available memory, we try to pick the worst offender.
Get the worst offender, not just who ever finally hit the limit.
> Actually a good Denial of service attack than can be used with cpusets > and memory policies.
Nothing special about cpusets there. The same DOS opportunity exists on simple one cpu, one node systems.
...
Granted, I am objecting to this patch with mixed feelings.
I've yet to be convinced that the oom killer is our friend, and half of me (not seriously) is almost wishing it were gone.
Would another option be to continue to fine tune the heuristics that the oom killer uses to pick its next victim?
What situation did you hit that motivated this change?
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.925.600.0401 - 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/
| |