> In reading some of the docs for this, I got the impression that CPPC can > basically be 2 things > > 1) A hardware controlled power governor, like our powerd or Linux's frequency > governors. > 2) A way to expose far more control over CPU frequency than pstates give us > (especially on AMD, where pstates generally only give 3 freqs)
That's essentially that, yes. Point 1) is optional. Part of it is implemented by the so-called "autonomous mode". On both AMD and Intel, you have to set the desired performance to 0 to enable this mode. Any other value disables it. In autonomous mode, you can use the EPP (Energy/Performance Preference) byte value to hint at wanting more performance (towards 0) or more efficiency (towards 255). The requested minimum and maximum performance (see next paragraph) may still have an effect. Point 2) can give you more fine-grained control over power (performance, consumption). First, you have to stop thinking in terms of frequency, switching instead to abstract numerical performance levels. A level is a number between 0 and 255, so you have at most 256 settings (in fact, 255 for the desired performance value, as value 0 is reserved for autonomous mode as said above). The number of them that are really different is however hardware-dependent (on a specific CPU model). CPPC will normally report the hardware minimum and maximum values, and you have all values in-between at your disposal to set the desired performance. However, besides the desired performance, there are two other controls: Requested minimum and maximum performances (by contrast with the hardware limits, into which they must of course lie). They limit the range in which the hardware is allowed to function. The desired performance must lie between the minimum and maximum requested. If all these values are not equal, the CPU is allowed (but not obliged) to temporarily change its balance around the desired performance, which is the other part of point 1). Setting all controls (minimum requested, desired performance and maximum requested) to the same value gives you some exact performance level, which can further be tuned with the EPP value. >> For the future, we should probably eye at teaching powerd(8) about working >> with CPPC, (snip) > (snip) However, I think (2) would let powerd do a far better job and I'd be > very interested in getting CPPC to optionally expose more frequencies and not > do any automatic governing. All CPPC controls I have mentioned are going to be exposed for AMD hardware very soon (reviews have been validated, I'm still polishing and testing some and will commit tomorrow probably). Goal is to expose the same controls for Intel hardware (which actually has some more, but that are tied to point 1)) in a second step. Then, what will be needed is to enhance powerd(8) to actually use these controls instead of setting frequencies (once CPPC is enabled, it's not possible to set frequencies, at least directly). Some experimentations will be needed to find the right policies, as the spec leaves an important leeway to hardware implementors. Policies may have to be tuned to the CPU brand, and even further to specific CPU models. E.g., on some AMD CPU I'm testing, the EPP value has absolutely no effect (whether in autonomous mode or not), and the size of the range of the requested minimum and maximum does not seem to matter (that still needs more experiments), so basically only the desired performance has an effect. On other Intel CPUs I tested, the EPP value has an important effect (in autonomous mode). -- Olivier Certner
signature.asc
Description: This is a digitally signed message part.
