svn commit: r209900 - head/sys/kern

[Bruce Evans]

On Tue, 13 Jul 2010, Alexander Motin wrote:

> Bruce Evans wrote:
>> Fix for cputick calibration:
>> ...
>> Variable frequencies have the interesting capability of varying in
>> both positive and negative directions.  This fixes the case of
>> negative-going changes.  ...
>
> 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.

It is only called from init_TSC() and tsc_levels_changed().  I don't
really understand tsc_xxx_change*().  It's interesting that the call
in tsc_levels_changed() passes `max_freq' as the frequency.  Is the
calibrator expected to reduce from a maximum frequency to a much
smaller throttled frequency?  But it can only go the other way without
my change.

>> 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.

When it is invariable, it is easy to determine precisely (just wait
long enough to find the average to the desired accuracy (this is only
seconds for 1 ppm even with a slow timecounter like ACPI-fast as a
reference).  Try ~bde/tsccalib/tsccalib.c on a FreeBSD cluster machine.
This requires all the CPUs to be in sync since it doesn't know how to
pin the thread to a CPU.

Bruce