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

[Chris Down]

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.