Re: [PATCH] sched: remove rq's runnable load average
From: Yuyang Du
Date: Fri Jun 06 2014 - 02:50:31 EST
On Thu, Jun 05, 2014 at 10:32:31AM +0200, Vincent Guittot wrote:
> Hi Yuyang,
>
> I have started to use it in this patchset https://lkml.org/lkml/2014/5/23/458
>
Hi Vincent and PeterZ,
I saw your patchset: https://lkml.org/lkml/2014/5/23/458. But don't take it
wrong, I did not intentionally attempt to remove rq->avg to prevent you from
using it. If your patchset gets merged, sure we should keep it. Otherwise, we
need to see whether there is other objection to remove it, because it has been
almost two years that is not used, I don't see any goodness of it in the
critical path but never used.
In addition, I want to market CPU ConCurrency (CC) as a candidate for CPU
unweighted load metric. Hope you can use it. And also try to answer
PeterZ's question: why not utilization, but CC?
CPU utilization, specifically CPU busy ratio, misses the tasks wanting/using
the CPU. I already explained it several times. So this time I'd like to make
some examples. Take 50% utilization for example, we really can't say 50% is
high or low for scheduler, because if it is just 1 task using it, it is low,
but if 100 tasks sharing it, it is already very high. And take 100%
utilization for example, if it is just 1 task, we can't say it is high in the
sense that give it another CPU does not help. So maybe you want to also
reference nr_running, but nr_running is too dynamic to use as it is.
On the contrary, CC understands not only CPU utilization but also tasks
utilizing the CPU. The averaged metric can 1) tolerate transient tasks as it
evens nr_running, and 2) know when CPU is utilized, because CC should be no
less than CPU utilization in general, 3) we just need to compare it with 1 as
the threshold, so not struggle in selecting what threshold to distinguish high
or low workload in the CPU utilization case. Right?
Thanks,
Yuyang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/