Re: [PATCH] sched/schedutil : optimize utilization scaling for guest kernel

[Vincent Guittot]

Le Wednesday 29 Aug 2018 à 14:45:03 (+0200), Peter Zijlstra a écrit :
> On Wed, Aug 29, 2018 at 10:51:42AM +0200, Vincent Guittot wrote:
> > Scaling the utilization of CPUs with irq util_avg in schedutil doesn't give
> > any benefit and just waste CPU cycles when irq time is not accounted but
> > only steal time.
> > Add an internal _scale_irq_capacity() for scale_rt_capacity but scale
> > cpu utilization in schedutil only if we are accounting irq time.
> 
> This makes a mess of things; also it doesn't really do what it says.

you're right. I forgot to not add irq util_avg in this case.
What about the below instead ?

sched/schedutil : optimize computation of utilization in schedutil
    
Scaling the utilization of CPUs with irq util_avg in schedutil doesn't give
any benefit and just waste CPU cycles when irq time is not accounted but
only steal time.
Skip the irq scaling when irq time is not accounted

Suggested-by: Wanpeng Li <kernellwp@xxxxxxxxx>
Signed-off-by: Vincent Guittot <vincent.guittot@xxxxxxxxxx>

---
 kernel/sched/cpufreq_schedutil.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 3fffad3..edbc4d2 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -238,6 +238,7 @@ static unsigned long sugov_get_util(struct sugov_cpu *sg_cpu)
 	if ((util + cpu_util_dl(rq)) >= max)
 		return max;
 
+#ifdef CONFIG_IRQ_TIME_ACCOUNTING
 	/*
 	 * There is still idle time; further improve the number by using the
 	 * irq metric. Because IRQ/steal time is hidden from the task clock we
@@ -249,6 +250,7 @@ static unsigned long sugov_get_util(struct sugov_cpu *sg_cpu)
 	 */
 	util = scale_irq_capacity(util, irq, max);
 	util += irq;
+#endif
 
 	/*
 	 * Bandwidth required by DEADLINE must always be granted while, for
-- 
2.7.4

> 
> Even if we have CONFIG_IRQ_TIME_ACCOUNTING, that doesn't mean we do it,
> just that it is capable.
> 
>