BUG in powersaved: cpufreq unreliable with Athlon64 X2 (dual core)
[already entered as BUG report into the powersaved project at sf] Hi, As far as I can tell, cpufreq/powersaved seems to have a problem with the Athlon64 X2 dual core chips. If I load just one core, the CPU frequency boost is unreliable (toggles between 1GHz and 2GHz). Loading the second core, too, sort-of-fixes that problem. The reason is obvious: The Athlon X2 has a *single* CPU frequency setting which affects *both* cores. So you can't simply use a SMP setting, treating the two CPUs as two processors with two speed settings, you have to know that it's a dual-core CPU, and that you can't independently set the CPU frequency. If one core is loaded, both must run at double frequency. Note that the kernel does know about this fact: /sys/devices/system/cpu/cpu0/cpufreq> cat affected_cpus 0 1 /sys/devices/system/cpu/cpu1/cpufreq> cat affected_cpus 0 1 Setting powersaved to be more verbose confirms the confusion (the following is with one core loaded by an endless loop, the other core loaded lightly): ------------------------------------------------- Nov 10 13:24:48 linux [powersave]: Info (setSpeed:90) Speed set to: 1800000KHz in file /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed Nov 10 13:24:48 linux [powersave]: Info (setSpeed:90) Speed set to: 2000000KHz in file /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed Nov 10 13:24:48 linux [powersave]: Info (adjustSpeed:196) Speed directly set to max (2000000) MHz Nov 10 13:24:48 linux [powersave]: Info (decreaseSpeed:138) current speed: 2000000KHz new speed: 1800000KHz Nov 10 13:24:48 linux [powersave]: Info (setSpeed:90) Speed set to: 1800000KHz in file /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed Nov 10 13:24:48 linux [powersave]: Info (adjustSpeed:207) Speed decreased to (1800000) MHz Nov 10 13:24:48 linux [powersave]: Info (decreaseSpeed:138) current speed: 2000000KHz new speed: 1800000KHz Nov 10 13:24:48 linux [powersave]: Info (setSpeed:90) Speed set to: 1800000KHz in file /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed Nov 10 13:24:48 linux [powersave]: Info (adjustSpeed:207) Speed decreased to (1800000) MHz Nov 10 13:24:48 linux [powersave]: Info (setSpeed:90) Speed set to: 2000000KHz in file /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed Nov 10 13:24:48 linux [powersave]: Info (adjustSpeed:196) Speed directly set to max (2000000) MHz Nov 10 13:24:48 linux [powersave]: Info (decreaseSpeed:138) current speed: 1800000KHz new speed: 1000000KHz Nov 10 13:24:48 linux [powersave]: Info (setSpeed:90) Speed set to: 1000000KHz in file /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed Nov 10 13:24:48 linux [powersave]: Info (adjustSpeed:207) Speed decreased to (1000000) MHz ------------------------------------------------- This seems to be a pretty severe bug, rendering powersaved pretty unusable on a dual-core Athlon64. I already checked the source, and there really is no code that looks at cpufreq/affected_cpus. There should be only one object per affected set of CPUs, and a list/bitset of processors instead of a single processor number. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
Bernd Paysan wrote:
[already entered as BUG report into the powersaved project at sf]
Hi,
As far as I can tell, cpufreq/powersaved seems to have a problem with the Athlon64 X2 dual core chips. If I load just one core, the CPU frequency boost is unreliable (toggles between 1GHz and 2GHz). Loading the second core, too, sort-of-fixes that problem.
The reason is obvious: The Athlon X2 has a *single* CPU frequency setting which affects *both* cores. So you can't simply use a SMP setting, treating the two CPUs as two processors with two speed settings, you have to know that it's a dual-core CPU, and that you can't independently set the CPU frequency. If one core is loaded, both must run at double frequency.
Note that the kernel does know about this fact:
/sys/devices/system/cpu/cpu0/cpufreq> cat affected_cpus 0 1 /sys/devices/system/cpu/cpu1/cpufreq> cat affected_cpus 0 1
Setting powersaved to be more verbose confirms the confusion (the following is with one core loaded by an endless loop, the other core loaded lightly):
------------------------------------------------- Nov 10 13:24:48 linux [powersave]: Info (setSpeed:90) Speed set to: 1800000KHz in file /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed Nov 10 13:24:48 linux [powersave]: Info (setSpeed:90) Speed set to: 2000000KHz in file /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed Nov 10 13:24:48 linux [powersave]: Info (adjustSpeed:196) Speed directly set to max (2000000) MHz Nov 10 13:24:48 linux [powersave]: Info (decreaseSpeed:138) current speed: 2000000KHz new speed: 1800000KHz Nov 10 13:24:48 linux [powersave]: Info (setSpeed:90) Speed set to: 1800000KHz in file /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed Nov 10 13:24:48 linux [powersave]: Info (adjustSpeed:207) Speed decreased to (1800000) MHz Nov 10 13:24:48 linux [powersave]: Info (decreaseSpeed:138) current speed: 2000000KHz new speed: 1800000KHz Nov 10 13:24:48 linux [powersave]: Info (setSpeed:90) Speed set to: 1800000KHz in file /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed Nov 10 13:24:48 linux [powersave]: Info (adjustSpeed:207) Speed decreased to (1800000) MHz Nov 10 13:24:48 linux [powersave]: Info (setSpeed:90) Speed set to: 2000000KHz in file /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed Nov 10 13:24:48 linux [powersave]: Info (adjustSpeed:196) Speed directly set to max (2000000) MHz Nov 10 13:24:48 linux [powersave]: Info (decreaseSpeed:138) current speed: 1800000KHz new speed: 1000000KHz Nov 10 13:24:48 linux [powersave]: Info (setSpeed:90) Speed set to: 1000000KHz in file /sys/devices/system/cpu/cpu0/cpufreq/scaling_setspeed Nov 10 13:24:48 linux [powersave]: Info (adjustSpeed:207) Speed decreased to (1000000) MHz -------------------------------------------------
This seems to be a pretty severe bug, rendering powersaved pretty unusable on a dual-core Athlon64.
I already checked the source, and there really is no code that looks at cpufreq/affected_cpus. There should be only one object per affected set of CPUs, and a list/bitset of processors instead of a single processor number.
Hi, Sorry for my ignorance of this topic, but does this mean that this bug in cpufreq will give much lower performance on these machines, since it will effectively nobble both cores making them run at 1GHz instead of 2.2GHz? Or will it just scale up according to need. Best wishes, Jon. -- Jonathan Brooks (Ph.D.) Research Assistant. PaIN Group, Department of Human Anatomy & Genetics, University of Oxford, South Parks Road, Oxford, OX1 3QX tel: +44(0)1865-282654 fax: +44(0)1865-282656 web: http://www.fmrib.ox.ac.uk/~jon
On Thursday 10 November 2005 18:59, Jonathan Brooks wrote:
Sorry for my ignorance of this topic, but does this mean that this bug in cpufreq will give much lower performance on these machines, since it will effectively nobble both cores making them run at 1GHz instead of 2.2GHz? Or will it just scale up according to need.
If only one core is loaded, both cores will toggle between 1GHz and 2.xGHz. If both cores are loaded, both will run at 2.x GHz (maximum frequency). To give an example: A benchmark that takes 1.3s with CPU frequency set to max, and 2.6s with CPU frequency set to min takes somewhere between 1.3s and 2.6s when set to "dynamic" (10 consecutive runs of the same benchmark): 1.55user 0.00system 0:01.57elapsed 99%CPU 1.31user 0.00system 0:01.32elapsed 99%CPU 1.34user 0.00system 0:01.36elapsed 99%CPU 1.80user 0.00system 0:01.82elapsed 99%CPU 2.66user 0.00system 0:02.68elapsed 99%CPU 2.64user 0.01system 0:02.66elapsed 99%CPU 2.63user 0.00system 0:02.63elapsed 100%CPU 2.63user 0.01system 0:02.65elapsed 99%CPU 2.65user 0.00system 0:02.66elapsed 99%CPU 1.40user 0.00system 0:01.42elapsed 99%CPU It *should* always take 1.3s, with the exception of the first run, which can take a little longer (powersaved needs some time to respond). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
On Friday 11 November 2005 13:35, Bernd Paysan wrote:
On Thursday 10 November 2005 18:59, Jonathan Brooks wrote:
Sorry for my ignorance of this topic, but does this mean that this bug in cpufreq will give much lower performance on these machines, since it will effectively nobble both cores making them run at 1GHz instead of 2.2GHz? Or will it just scale up according to need.
If only one core is loaded, both cores will toggle between 1GHz and 2.xGHz. If both cores are loaded, both will run at 2.x GHz (maximum frequency).
I wrote a patch, only for the userspace part. Seems to work (limit: 64 CPUs). -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
On Friday 11 November 2005 17:46, Bernd Paysan wrote:
I wrote a patch, only for the userspace part. Seems to work (limit: 64 CPUs).
Simpler fix: Just delete the "userspace" from the CPUFREQ_CONTROL variable in the /etc/sysconfig/powersave/cpufreq file, and use the kernel part. This one works. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
participants (3)
-
Andi Kleen -
Bernd Paysan -
Jonathan Brooks