From owner-freebsd-acpi@FreeBSD.ORG Sat Nov 20 10:11:59 2010 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 428E11065670; Sat, 20 Nov 2010 10:11:59 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 58E9A8FC1A; Sat, 20 Nov 2010 10:11:57 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id MAA26967; Sat, 20 Nov 2010 12:11:55 +0200 (EET) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1PJkQF-0000jM-16; Sat, 20 Nov 2010 12:11:55 +0200 Message-ID: <4CE79EEA.9060200@freebsd.org> Date: Sat, 20 Nov 2010 12:11:54 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.12) Gecko/20101029 Lightning/1.0b2 Thunderbird/3.1.6 MIME-Version: 1.0 To: Nate Lawson References: <4CE579DD.2030406@freebsd.org> <4CE5A282.1000300@root.org> In-Reply-To: <4CE5A282.1000300@root.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org, freebsd-current@freebsd.org Subject: Re: ideas for _PSD/_CSD/_TSD X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Nov 2010 10:11:59 -0000 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