Re: ideas for _PSD/_CSD/_TSD

On 11/18/2010 11:09 AM, Andriy Gapon wrote:
> I am trying to solicit some architectural/design ideas for implementing logic that
> would honor ACPI _PSD/_CSD/_TSD descriptions of processor dependency domains.
> Well, I am primarily interested in _PSD, but I think that some general principles
> could be shared.
> 
> In simple terms.
> Currently we do only the "global" P-state management.  cpufreq advertises a common
> set of frequencies/P-states and a single P-state/frequency is set on all (logical)
> processors by e.g. powerd based on global system load.
> The downsides are obvious, I think.
> 
> Modern systems can provide _PSD method which describes grouping of logical
> processors into P-state domains and nature of dependency between the processors in
> the domain.  E.g. on some systems putting a single processor from the domain into
> a Px state results in all the processors being put into that state.  On other
> systems, all processors have to be put into the same state for it to become
> effective.  On yet other systems there could be no coordination required between
> the processors (even when they are all cores in the same package), so each would
> be placed in its own domain.
> 
> I think that this issue may get more prominence because of the new technologies
> that combine power saving with "turbo boosting".  E.g. there could be a technology
> where some processor's performance would only be boosted if other processors are
> at or above some state Pt.  With current cpufreq design we would not be able to
> take an advantage of that, because we always put all the processors into the same
> state.

As you can see from the codebase, cpufreq was designed with this model
in mind. I spent a lot of work adding the cpu devices to newbus in order
to have cpufreq attach per-cpu. Each instance has its own dev.cpu.X.freq
setting.

Of course, there weren't any asymmetrical CPU Px states back then so
calculation of levels is shared as you point out. But since it's done in
cpufreq attach(), it is easy to make that independent while still
merging states with global settings (e.g., p4tcc relative levels that
apply system-wide, not per-cpu).

What you want is to have a flag that indicates if Px states are global
or not. If global, you can still attach a cpufreq device to each cpu but
make changing any of their settings loop through changing all cpu
settings equally. This is how it currently works. If the flag is false,
then only apply a setting to the device it was received on.

-- 
Nate