Re: ideas for _PSD/_CSD/_TSD

on 19/11/2010 00:02 Nate Lawson said the following:
> 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.

Yes, I do see that.  Thanks!

> 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).

Indeed.

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

Yes.
But I am not sure right now where to put and how query the _PSD information.
Most likely this should to acpi_perf.  Then the hardware-specific drivers under
acpi_perf (if any) could obtain the information from acpi_perf.
Some questions then - should we attach one instance of acpi_perf under each CPU
or once per domain (to an arbitrary CPU in each domain).  Ditto for the hardware
specific drivers.

-- 
Andriy Gapon