From owner-freebsd-current@FreeBSD.ORG Thu Nov 18 22:20:06 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5CC11106564A; Thu, 18 Nov 2010 22:20:06 +0000 (UTC) (envelope-from nate@root.org) Received: from mail.root.org (root.org [208.72.84.34]) by mx1.freebsd.org (Postfix) with ESMTP id CC6D18FC13; Thu, 18 Nov 2010 22:20:05 +0000 (UTC) Received: from [10.1.0.198] (dsl081-053-082.sfo1.dsl.speakeasy.net [64.81.53.82]) by mail.root.org (Postfix) with ESMTP id A98B06ECE; Thu, 18 Nov 2010 22:02:44 +0000 (UTC) Message-ID: <4CE5A282.1000300@root.org> Date: Thu, 18 Nov 2010 14:02:42 -0800 From: Nate Lawson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: freebsd-acpi@freebsd.org References: <4CE579DD.2030406@freebsd.org> In-Reply-To: <4CE579DD.2030406@freebsd.org> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ideas for _PSD/_CSD/_TSD X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2010 22:20:06 -0000 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. 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). 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. -- Nate