svn commit: r209900 - head/sys/kern
Alexander Motin
mav at FreeBSD.org
Tue Jul 13 07:52:51 UTC 2010
Bruce Evans wrote:
> Fix for cputick calibration:
>
> % diff -c2 ./kern/kern_tc.c~ ./kern/kern_tc.c
> % *** ./kern/kern_tc.c~ Thu Mar 20 01:05:27 2008
> % --- ./kern/kern_tc.c Thu Mar 20 01:05:29 2008
> % ***************
> % *** 884,888 ****
> % return;
> % % ! getbinuptime(&t_this);
> % c_this = cpu_ticks();
> % if (t_last.sec != 0) {
> % --- 884,888 ----
> % return;
> % % ! binuptime(&t_this);
> % c_this = cpu_ticks();
> % if (t_last.sec != 0) {
>
> Minor fix for accuracy.
>
> % ***************
> % *** 922,931 ****
> % c_delta <<= 20;
> % c_delta /= divi;
> % ! if (c_delta > cpu_tick_frequency) {
> % ! if (0 && bootverbose)
> % ! printf("cpu_tick increased to %ju Hz\n",
> % ! c_delta);
> % ! cpu_tick_frequency = c_delta;
> % ! }
> % }
> % }
> % --- 922,930 ----
> % c_delta <<= 20;
> % c_delta /= divi;
> % ! if (0 && bootverbose)
> % ! printf(
> % ! "cpu_tick_frequency changed from %ju to %ju Hz\n",
> % ! cpu_tick_frequency, c_delta);
> % ! cpu_tick_frequency = c_delta;
> % }
> % }
>
> Variable frequencies have the interesting capability of varying in
> both positive and negative directions. This fixes the case of
> negative-going changes. Without this, the overflowing timecounter
> cases caused cpu_tick_frequency to become huge (100's of times the
> correct value), and it was clamped to the hugest value ever seen. The
> way this mostly fixes the problem is that cpu_tick_frequency can be
> off by a factor of 100, but only for 16 seconds or so until the next
> calibration fixes it.
I have no hardware to check, but I have feeling that calibration didn't
work well also for older CPUs with variable TSC frequency, when
frequency is decreasing. I see TSC timecounter frequency changed at
tsc_freq_changed(), but set_cputicker() is not called there to adopt it,
neither calibration can reduce it by itself.
> I don't use this in the same kernels that have the fix for the
> timecounters. An integrated fix would prevent recalibration until 16
> seconds after the timecounter has been restored.
>
> Setting cpu_tick_variable to 0 is an even simpler fix if the cputicker
> is not very variable.
Yes. In fact cputicker is invariable for the most of modern x86 CPUs.
But it's frequency is not always precisely known.
> Without this, normal frequency drift due to temperature changes caused
> cpu_tick frequency to become larger than the correct value by a few
> ppm. Again it was clamped to the largest value ever seen, but errors
> of a few ppm are hard to see.
--
Alexander Motin
More information about the svn-src-head
mailing list