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 -- 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/
