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