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
___
freebsd-acpi@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
