On 07-Aug 14:54, Quentin Perret wrote:

Hi Patrick,

Hi Quentin!

On Monday 06 Aug 2018 at 17:39:38 (+0100), Patrick Bellasi wrote:

quoted

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index a7affc729c25..bb25ef66c2d3 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c

@@ -200,6 +200,7 @@ static unsigned int get_next_freq(struct sugov_policy *sg_policy,
 static unsigned long sugov_get_util(struct sugov_cpu *sg_cpu)
 {
 	struct rq *rq = cpu_rq(sg_cpu->cpu);
+	unsigned long util_cfs, util_rt;
 	unsigned long util, irq, max;
 
 	sg_cpu->max = max = arch_scale_cpu_capacity(NULL, sg_cpu->cpu);

IIUC, not far below this you should still have something like:

	if (rt_rq_is_runnable(&rq->rt))
		return max;

Do you mean that when RT tasks are RUNNABLE we still want to got to
MAX? Not sure to understand... since this patch is actually to clamp
the RT class...

So you won't reach the actual clamping code at the end of the function
when a RT task is runnable no?

... mmm... no... this patch is to clamp RT tasks... Am I missing
something?

Also, I always had the feeling that the default for RT should be
util_min == 1024, and then users could decide to lower the bar if they
want to.

Mmm... good point! This would keep the policy unaltered for RT tasks.

I want to keep sched class specific code in uclamp at minimum, but
likely this should be achievable by just properly initializing the
task-specific util_min for RT tasks, if the original task has
UCLAM_NOT_VALID.

For the specific case of RT, that feels more natural than
applying a max util clamp IMO. What do you think ?

I'll look better into this for the next posting!

Cheers Patrick

-- 
#include <best/regards.h>

Patrick Bellasi