Date: Sat, 20 Nov 2010 12:11:54 +0200 From: Andriy Gapon <avg@freebsd.org> To: Nate Lawson <nate@root.org> Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: ideas for _PSD/_CSD/_TSD Message-ID: <4CE79EEA.9060200@freebsd.org> In-Reply-To: <4CE5A282.1000300@root.org> References: <4CE579DD.2030406@freebsd.org> <4CE5A282.1000300@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CE79EEA.9060200>