SourceForge.net wrote:

Bugs item #1353119, was opened at 2005-11-10 13:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=700009&aid=1353119&group_id=124576

Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Bernd Paysan (paysan) Assigned to: Nobody/Anonymous (nobody) Summary: cpufreq unreliable with Athlon64 X2 (dual core)

Initial Comment: Hi,

As far as I can tell, cpufreq/powersaved (of 0.10.15.1, as in SuSE 10.0) seems to have a severe 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.

So the assumption, that the higher value when writing to two sibling cores is taken is wrong, but the last value written is taken? See below.

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

Yes, I have done this already for SLES9-SP2. IIRC there was no affected_cpus file in 2.6.5, so I had to parse /proc/cpuinfo for siblings and cores.

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

I remember Mark Langsdorf telling me that if two speeds are set for two cores on the same socket, the higher one will be activated on both. For this case the old alogrithm should still be sufficient and the concerns for 10.0 stated above should not be the case, but I maybe wrong here. Hmm, I just rechecked. This cannot be the case for newer kernels any more as there /sys/devices/.../cpu0/cpufreq is a link to /sys/devices/.../cpu1/cpufreq so probably the last speed written into one of them gets the active freq. The cpumask approach patch looks nice, but for a quick look, it's not complete (it should need a hack in adjustSpeed function itself, setMode should only be invoked once when the user switches between e.g. dynamic to performance mode). We should either: 1) only create one object per cpu socket that sets the speed for all its cores. Probably the nicer solution (but IIRC needs some redoing of code to be able to access/create file paths to the other CPU(s). 2) Still use CPU core objects and set the speed according to the max Load of both. Disadvantage: memory/performance waste (two objects for 1 socket and two times written into each core). Ok, I just talked with Holger and he already has something. If I understood him right, he goes for 1. based on Bernd's patch and workarounds the accessing file paths problem by checking and ignoring the symlink directory. Be careful that this only works on very current kernels as those symlink directories for dual cores seem to be introduced very recently. We should also check whether all cpufreq drivers (speedstep-centrino, powernow-k8 and acpi-cpufreq) are behaving in the same way. Thanks a lot Bernd and Holger for finding and fixing this, Thomas