Michal Hocko writes:
I have a good reason why we shouldn't: because it's special casing
memory.high from other forms of reclaim, and that is a maintainability
problem. We've recently been discussing ways to make the memory.high
implementation stand out less, not make it stand out even more. There
is no solid reason it should be different from memory.max reclaim,
except that it should sleep instead of invoke OOM at the end. It's
already a mess we're trying to get on top of and straighten out, and
you're proposing to add more kinks that will make this work harder.
I do see your point of course. But I do not give the code consistency
a higher priority than the potential unfairness aspect of the user
visible behavior for something that can do better. Really the direct
reclaim unfairness is really painfull and hard to explain to users. You
can essentially only hand wave that system is struggling so fairness is
not really a priority anymore.
It's not handwaving. When using cgroup features, including memory.high, the
unit for consideration is a cgroup, not a task. That we happen to act on
individual tasks in this case is just an implementation detail.
That one task in that cgroup is may be penalised "unfairly" is well within the
specification: we set limits as part of a cgroup, we account as part of a
cgroup, and we throttle and reclaim as part of a cgroup. We may make some very
rudimentary attempts to "be fair" on a per-task basis where that's trivial, but
that's just one-off niceties, not a statement of precedent.
When exceeding memory.high, the contract is "this cgroup must immediately
attempt to shrink". Breaking it down per-task in terms of fairness at that
point doesn't make sense: all the tasks in one cgroup are in it together.
