On 6 May 2015 at 04:34, Juri Lelli juri.lelli@arm.com wrote:
Hi Mike, On 06/05/15 01:58, Mike Turquette wrote:
On Tue, May 5, 2015 at 3:12 AM, Juri Lelli juri.lelli@arm.com wrote:
Hi Ashwin,
So, the energy model (and please mind that the patches on top of Mike's patchset don't have that yet) currently gives you these "capacity bands". The idea is to try to adapt the OPP selection to the usage you see on your CPU/cluster. Since the usage signal is subject to saturation, what I'm trying to do is to avoid this condition by jumping up to the max available OPP when we realize that we are going to saturate a particular OPP. After we run for a small interval of time (say a tick) at that max OPP we can better estimate the real usage and directly select an OPP ("capacity band") that suits it.
I'm not sure about jumping to the max frequency when we detect that the signal is saturated.
Ondemand has similar behavior to this and many vendors have implemented out-of-tree solutions that do something like setting the frequency to an "intermediate" rate (maybe 2/3 of the total performance band) and then re-evaluate if they need to jump to max performance after another sampling period.
So at some point you might face the same issue where vendors find this approach too aggressive and wastes too much power, thus some intermediate level will be introduced. I'm not providing you any solutions here, but I'm saying that designing a policy algorithm that works well for everyone is super hard.
No doubt about this :).
I got your point, but I guess it should be fairly easy to make this freq at which we jump somewhat "configurable". Makes sense to me, considering the variety of shapes power-perf curves can have, for example.
Instead of another knob, perhaps we could make the 25% headroom flexible by adapting it to current vs past utilization? Not something we need to start off with, but a possible future optimization.
I see your point, though. I think the two approaches differ for how we get to the desired capacity: ramping up from bottom vs. selecting from top.
From the energy model perspective, can a continuous performance band be supported at all or is it a hard requirement to have a discretized table?
I don't think it's a hard requirement (Morten or Dietmar may correct me here), but just an abstraction of the systems we develop onto today. I guess we would need to compute some formulas at run time, instead of reading tabular values, if we want to have continuous performance bands. Food for thought :).
We could also tablify continuous frequency domains based on some reasonable factor like 50Mhz or something. I guess that factor could even be supplied by the driver.
Agree. That's what I was thinking with "discretize continuous systems".
Sounds possible. Probably not a big deal, but theres a chance of losing out some power optimization depending on how many discrete steps you make. A matter of system profiling I guess.
Regards, Ashwin.