This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH] x86/cpufreq: fix turbo mode detection

To: "Keir Fraser" <keir.fraser@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] x86/cpufreq: fix turbo mode detection
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Date: Thu, 06 May 2010 16:25:03 +0100
Cc: "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 06 May 2010 08:24:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <C8089BF9.13693%keir.fraser@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <4BE2DBD4020000780000191E@xxxxxxxxxxxxxxxxxx> <C8089BF9.13693%keir.fraser@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>> Keir Fraser <keir.fraser@xxxxxxxxxxxxx> 06.05.10 17:16 >>>
>On 06/05/2010 14:10, "Jan Beulich" <JBeulich@xxxxxxxxxx> wrote:
>> acpi_cpufreq_cpu_init() does generally not run on the CPU the policy
>> it deals with is related to, hence using cpuid() directly works only
>> as long as all CPUs in the system are identical (which admittedly
>> is commonly the case).
>Doesn't the fact that acpi_cpufreq_driver.getavg is a single global function
>pointer defeat the object of this patch? The effect of proper localised
>checking of cpuid_ecx(6) is still global.
>The check of cpuid_eax(6) yields a localised effect (on policy->turbo, where
>policy does appear to be per-cpu). But whether 'fixing' that but not
>properly the other is worthwhile, I'm not sure.

Yes, only one of the two were really an issue, but since I needed
to move part of this code around, I decided to move it all at once
in case later other bits (with non-global) meaning would get used.

>> Also fix a minor glitch in xenpm, which I noticed while looking into
>> the original inconsistencies on one of my systems.
>Would belong in a separate patch. Also it's not clear to me what the
>'glitch' is. Printing an asterisk might be frivolous/pointless, but is it

Yes, it printed the * on the wrong field (used the CPU number as an
index into an array consisting of only the members of one domain).


Xen-devel mailing list