Right, but you didn't explicitly prohibit such applications from being
killed, so that suggests that doing so may be inconvenient but doesn't
incur something like corruption or data loss, which is what I would
consider "unstable" or "inconsistent" state.
We're trying to avoid any additional heuristics from being introduced for
specific usecases, even for Xorg. That ensures that the heuristic remains
as predictable as possible and frees a large amount of memory. If Xorg is
being killed first instead of a true memory hogger, then it seems like a
forkbomb scenario instead; could you please post your kernel log so that
we can diagnose that issue seperately?
The old heuristic would allow it to elude the oom killer because it would
divide the score by four if a task had the capability, which is a much
more drastic "bonus" than you suggest here. That would reduce the score
for the memory hogging task significantly enough that we killed tons of
innocent tasks instead before eventually killing the task that was leaking
memory but failed to be identified because it had CAP_SYS_RAWIO. I'm
trying to avoid any such repeats.
--
