On Mon 14. Nov - 10:48:41, Thomas Renninger wrote:
> 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.
If the symlink does not exist, there is also no cpufreq directory and the
core is skipped anyway. So it shouldn't matter which kernel is used.
>
> Thanks a lot Bernd and Holger for finding and fixing this,
I already commited to cvs head.
Regards,
Holger
_______________________________________________
powersave-devel mailing list
[email protected]
http://forge.novell.com/mailman/listinfo/powersave-devel
