svn commit: r209900 - head/sys/kern

[Alexander Motin]

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