[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



>>> 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
>wrong?

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).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.