Messages in this thread | | | Date | Fri, 6 Jun 2014 06:46:29 +0800 | From | Yuyang Du <> | Subject | Re: [PATCH] sched: remove rq's runnable load average |
| |
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
| |