Messages in this thread | | | Subject | Re: [PATCH] Allow all Opteron processors to change pstate at same time | From | Andi Kleen <> | Date | 07 Jul 2006 14:10:14 +0200 |
| |
"Mark Langsdorf" <mark.langsdorf@amd.com> writes:
[cc'ing back to discuss and cpufreq]
> The current generation of Opteron processors do not provide a frequency > independent TSC. This causes wild gettimeofday skew on systems that > enable cpufreq while using TSC as a gtod source. > > This patch provides a workaround by changing all processors to the same > frequency at the same time, so that the TSC on each processor never > increments at a different rate than the TSC on another processor. > > the "powernow-k8.tscsync=1" options enables simeltameous transitions. > Other options are necessary to force the use of TSC as a gtod source. > > This patch should apply cleanly to the 2.6.18-rc1 kernel.
Your patch seems to be ^M damaged.
I'm still dubious if the result is really correct if the hardware wasn't designed to guarantee synchronous TSC operation.
Can you do the following test please?
- Set this option - Let the system run for let's say a day or two with some freq transitions and varying loads [Better would be to let two systems run in this way to compare] - Then hotunplug all the CPUs >0 with for i in /sys/devices/system/cpu/cpu*/online ; do echo 0 > $i ; done - Wait a bit - Restart them again with for i in /sys/devices/system/cpu/cpu*/online ; do echo 1 > $i ; done
The kernel should now print the results of the TSC resync for the replugged CPUs with output like this
CPU N: Syncing TSC to CPU 0. CPU N: synchronized TSC with CPU 0 (last diff XXX cycles, maxerr YYY cycles)
How do these numbers look like, also compared to the original boot output?
If the cycles diverge more between the different CPUs it would be a bad sign. It would mean that the error would add up over longer runtime and timing would get more and more unstable.
-Andi
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |