Re: [PATCH v3 06/14] sched/cpufreq: uclamp: add utilization clamping for RT tasks

From: Dietmar Eggemann
Date: Thu Aug 16 2018 - 06:34:14 EST

On 08/13/2018 05:01 PM, Patrick Bellasi wrote:
On 13-Aug 16:06, Vincent Guittot wrote:
On Mon, 13 Aug 2018 at 14:49, Patrick Bellasi <patrick.bellasi@xxxxxxx> wrote:
On 13-Aug 14:07, Vincent Guittot wrote:
On Mon, 13 Aug 2018 at 12:12, Patrick Bellasi <patrick.bellasi@xxxxxxx> wrote:


Yes I agree that the current behavior is not completely clean... still
the question is: do you reckon the problem I depicted above, i.e. RT
workloads eclipsing the min_util required by lower priority classes?

As said above, I don't think that there is a problem that is specific
to cross class scheduling that can't also happen in the same class.

Regarding your example:
task TA util=40% with uclamp_min 50%
task TB util=10% with uclamp_min 0%

If TA and TB are cfs, util=50% and it doesn't seem to be a problem
whereas TB will steal some bandwidth to TA and delay it (and i even
don't speak about the impact of the nice priority of TB)
If TA is cfs and TB is rt, Why util=50% is now a problem for TA ?

You right, in the current implementation, where we _do not_
distinguish among scheduling classes it's not possible to get a
reasonable implementation of a per sched class clamping.

To a certain extend I see this problem similar to the rt/dl/irq pressure
in defining cpu_capacity, isn't it?

However, I still think that higher priority classes eclipsing the
clamping of lower priority classes can still be a problem.

In your example above, the main difference between TA and TB being on
the same class or different classes is that in the second case TB
is granted to always preempt TA. We can end up with a non boosted RT
task consuming all the boosted bandwidth required by a CFS task.

This does not happen, apart maybe for the corner case of really
different nice values, if the tasks are both CFS, since the fair
scheduler will grant some progress for both of them.

Thus, given the current implementation, I think it makes sense to drop
the UCLAMP_SCHED_CLASS policy and stick with a more clean and
consistent design.

I agree with everything said in this thread so far.
So in case you skip UCLAMP_SCHED_CLASS [(B) combine the clamped utilizations] in v4, you will only provide [A) clamp the combined utilization]?

I assume that we don't have to guard the util clamping for rt tasks behind a disabled by default sched feature because all runnable rt tasks will have util_min = SCHED_CAPACITY_SCALE by default?

I'll then see if it makes sense to add a dedicated patch on top of the
series to add a proper per-class clamp tracking.

I assume if you introduce this per-class clamping you will switch to use the UCLAMP_SCHED_CLASS approach?