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
_______________________________________________
powersave-devel mailing list
[email protected]
http://forge.novell.com/mailman/listinfo/powersave-devel
