On Fri, Jun 06, 2014 at 04:29:30AM +0800, Yuyang Du wrote: > 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.
*sigh* and here we go again.. someone please, write something coherent and have all intel people sign off on it and stop saying different things. > Actually, silicon supports indepdent non-Turbo pstate, but just not enabled. Then it doesn't exist, so no point in mentioning it. > 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 RAPL controls can give preference of which gfx/core gets most, right? > > 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. So frequency isn't _that_ interesting, voltage is. And while predictability it might be their assumption, is it actually true? I mean, there's really nothing else except to assume that, if its not you can't do anything at all, so you _have_ to assume this. But again, is the assumption true? Or just happy thoughts in an attempt to do something.
pgpdac4UnAivI.pgp
Description: PGP signature
