Re: [PATCH] mm, memcg: reclaim more aggressively before high allocator throttling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux