Messages in this thread | | | Date | Fri, 6 Jun 2014 04:29:30 +0800 | From | Yuyang Du <> | Subject | Re: [RFC PATCH 06/16] arm: topology: Define TC2 sched energy and provide it to scheduler |
| |
On Thu, Jun 05, 2014 at 08:03:15AM -0700, Dirk Brandewie wrote: > > You can request a P state per core but the package does coordination at > a package level for the P state that will be used based on all requests. > This is due to the fact that most SKUs have a single VR and PLL. So > the highest P state wins. When a core goes idle it loses it's vote > for the current package P state and that cores clock it turned off. >
You need to differentiate Turbo and non-Turbo. The highest P state wins? Not really. Actually, silicon supports indepdent non-Turbo pstate, but just not enabled. For Turbo, it basically depends on power budget of both core and gfx (because they share) for each core to get which Turbo point.
> > > >And while APERF/MPERF allows observing what it did, its afaik, nigh on > >impossible to predict wtf its going to do, and therefore any such energy > >computation is going to be a PRNG at best. > > > >Now, given all that I'm not sure what we need that P-state driver for, > >so supposedly I'm missing something. > > intel_pstate tries to keep the core P state as low as possible to satisfy > the given load, so when various cores go idle the package P state can be > as low as possible. The big power win is a core going idle. >
In terms of prediction, it is definitely can't be 100% right. But the performance of most workloads does scale with pstate (frequency), may not be linearly. So it is to some point predictable FWIW. And this is all governors and Intel_pstate's basic assumption.
Thanks, Yuyang
| |