Messages in this thread | | | Date | Mon, 9 Jun 2014 10:15:16 +0800 | From | Yuyang Du <> | Subject | Re: [RFC PATCH 06/16] arm: topology: Define TC2 sched energy and provide it to scheduler |
| |
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
| |