Michal Hocko writes:
On Thu 21-05-20 13:57:59, Chris Down wrote:
Michal Hocko writes:
> > A cgroup is a unit and breaking it down into "reclaim fairness" for
> > individual tasks like this seems suspect to me. For example, if one task in
> > a cgroup is leaking unreclaimable memory like crazy, everyone in that cgroup
> > is going to be penalised by allocator throttling as a result, even if they
> > aren't "responsible" for that reclaim.
>
> You are right, but that doesn't mean that it is desirable that some
> tasks would be throttled unexpectedly too long because of the other's activity.
Are you really talking about throttling, or reclaim? If throttling, tasks
are already throttled proportionally to how much this allocation is
contributing to the overage in calculate_high_delay.
Reclaim is a part of the throttling mechanism. It is a productive side
of it actually.
I guess let's avoid using the term "throttling", since in this context it
sounds like we're talking about allocator throttling :-)
If you're talking about reclaim, trying to reason about whether the overage
is the result of some other task in this cgroup or the task that's
allocating right now is something that we already know doesn't work well
(eg. global OOM).
I am not sure I follow you here.
Let me rephrase: your statement is that it's not desirable "that some task
would be throttled unexpectedly too long because of [the activity of another
task also within that cgroup]" (let me know if that's not what you meant). But
trying to avoid that requires knowing which activity abstractly instigates this
entire mess in the first place, which we have nowhere near enough context to
determine.
