Bug in cpufreq-utils (/sys/devices/system/cpu/cpu*/cpufreq/affected_cpus)?

Bug in cpufreq-utils (/sys/devices/system/cpu/cpu*/cpufreq/affected_cpus)?

[Ulrich Windl]

Hello,

I found this for cpufrequtils-004-35.20 on SLES11 SP1 (plus updates) for a HP DL380 G7 server with two 6-core Xeon X5650 CPUs:

...
analyzing CPU 23:
  driver: pcc-cpufreq
  CPUs which need to switch frequency at the same time: 23
  hardware limits: 1.60 GHz - 2.67 GHz
  available cpufreq governors: conservative, userspace, powersave, ondemand, performance
  current policy: frequency should be within 1.60 GHz and 2.67 GHz.
                  The governor "ondemand" may decide which speed to use
                  within this range.
  current CPU frequency is 1.57 GHz (asserted by call to hardware).

To my understanding "cpu23" in Linux is "package 1 (2nd CPU), core 9 (actually 4/6 or 6/6), ACPI ID 51". As each core is featuring hyper-theading I wonder whether two threads may actually be clocked individually. If not, "cpu11" (package 1 (2nd CPU), core 9 (actually 4/6 or 6/6), ACPI ID 50) should need to switch frequency, too.

# cat /sys/devices/system/cpu/cpu23/cpufreq/affected_cpus
23
# cat /proc/version
Linux version 2.6.32.29-0.3-default (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP 2011-02-25 13:36:59 +0100

Regards,
Ulrich
P.S. I'm not subscribed to this list, so maybe CC: your answers - thanks!

pcc-cpufreq bug [Was: Bug in cpufreq-utils (/sys/devices/system/cpu/cpu*/cpufreq/affected_cpus)?]

[Dominik Brodowski]

Hey,

On Thu, Apr 07, 2011 at 04:53:21PM +0200, Ulrich Windl wrote:
> Hello,
> 
> I found this for cpufrequtils-004-35.20 on SLES11 SP1 (plus updates) for a HP DL380 G7 server with two 6-core Xeon X5650 CPUs:
> 
> ...
> analyzing CPU 23:
>   driver: pcc-cpufreq
>   CPUs which need to switch frequency at the same time: 23
>   hardware limits: 1.60 GHz - 2.67 GHz
>   available cpufreq governors: conservative, userspace, powersave, ondemand, performance
>   current policy: frequency should be within 1.60 GHz and 2.67 GHz.
>                   The governor "ondemand" may decide which speed to use
>                   within this range.
>   current CPU frequency is 1.57 GHz (asserted by call to hardware).
> 
> To my understanding "cpu23" in Linux is "package 1 (2nd CPU), core 9 (actually 4/6 or 6/6), ACPI ID 51". As each core is featuring hyper-theading I wonder whether two threads may actually be clocked individually. If not, "cpu11" (package 1 (2nd CPU), core 9 (actually 4/6 or 6/6), ACPI ID 50) should need to switch frequency, too.
> 
> # cat /sys/devices/system/cpu/cpu23/cpufreq/affected_cpus
> 23

Thanks for reporting this issue. However, cpufrequtils is rather dumb in
this regard, and just makes use of the values reported by the kernel. And
the kernel reports that changing the frequency of CPU 23 only affects CPU
23... Which is obviously wrong.

To the pcc-cpufreq.c driver developers & maintainers: Is there _any_ way to
properly set

	(struct cpufreq_policy *) -> cpus
				  -> related_cpus

in this driver?

Best,
	Dominik

Re: pcc-cpufreq bug [Was: Bug in cpufreq-utils (/sys/devices/system/cpu/cpu*/cpufreq/affected_cpus)?]

[Matthew Garrett]

On Tue, Apr 12, 2011 at 10:39:15PM +0200, Dominik Brodowski wrote:

> To the pcc-cpufreq.c driver developers & maintainers: Is there _any_ way to
> properly set
> 
> 	(struct cpufreq_policy *) -> cpus
> 				  -> related_cpus
> 
> in this driver?

The spec says we should be able to do this with the _PSD data. I'll look 
into it.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: pcc-cpufreq bug [Was: Bug in cpufreq-utils (/sys/devices/system/cpu/cpu*/cpufreq/affected_cpus)?]

[Dominik Brodowski]

On Tue, Apr 12, 2011 at 09:48:11PM +0100, Matthew Garrett wrote:
> On Tue, Apr 12, 2011 at 10:39:15PM +0200, Dominik Brodowski wrote:
> 
> > To the pcc-cpufreq.c driver developers & maintainers: Is there _any_ way to
> > properly set
> > 
> > 	(struct cpufreq_policy *) -> cpus
> > 				  -> related_cpus
> > 
> > in this driver?
> 
> The spec says we should be able to do this with the _PSD data. I'll look 
> into it.

Thanks!

	Dominik