> 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 <[email protected]> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
