On Mon, Jun 09, 2014 at 09:59:52AM +0100, Morten Rasmussen wrote: > IMHO, the per-entity load-tracking does a fair job representing the task > compute capacity requirements. Sure it isn't perfect, particularly not > for memory bound tasks, but it is way better than not having any task > history at all, which was the case before. > > The story is more or less the same for performance scaling. It is not > taken into account at all in the scheduler at the moment. cpufreq is > actually messing up load-balancing decisions after task load-tracking > was introduced. Adding performance scaling awareness should only make > things better even if predictions are not accurate for all workloads. I > don't see why it shouldn't given the current state of energy-awareness > in the scheduler. >
Optimized IPC is good for sure (with regard to pstate adjustment). My point is how it is practical to rightly correlate to scheduler and pstate power-efficiency. Put another way, with fixed workload, you really can do such a thing by offline running the workload several times to conclude with a very power-efficient solution which takes IPC into account. Actually, lots of people have done that in papers/reports (for SPECXXX or TPC-X for example). But I can't see how online realtime workload can be done like it. > > Currently, all freq governors take CPU utilization (load%) as the indicator > > (target), which can server both: workload and perf scaling. > > With a bunch of hacks on top to make it more reactive because the > current cpu utilization metric is not responsive enough to deal with > workload changes. That is at least the case for ondemand and interactive > (in Android). > To what end it is not responsive enough? And how it is related here? Thanks, Yuyang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
