On Tue, 12 Aug 2003, Jun Sun wrote:
> > As a number of interrupts is lost (at least half a second worth of; it
> > depends on how long console_init() executes), it takes a few minutes for
> > gettimeoffset() to recover from the error -- r0 (which is the number of
> > HPT ticks in a jiffy) is too high. As a result, offsets within jiffies as
> > calculated by gettimeoffset() are distributed unevenly. You may not care,
> > but I use NTP on my systems and I do care. With the above initialization,
> > r0 is almost correct from the beginning and after a few minutes of uptime
> > the error is no higher than one tick.
> >
> > The fixed_rate_gettimeoffset() backend doesn't care but the calibrate_*()
> > ones do.
>
> Perhaps we should always calibrate the counter frequency and forget about
> all those calibrate_*() routines. This will allow us to get rid of a few
> funtions. Plus knowing the frequency is generally a good thing (for some
> performance measurement, for example).
Of course calibrating the counter frequency beforehand would be a Good
Thing, but that's not exactly trivial.
> I have a patch floating around just doing that, and in MontaVista tree
> we have already done for a long time.
>
> The patch is at
>
> http://linux.junsun.net/patches/oss.sgi.com/experimental/011128.calibrate_mips_counter.patch
>
> (Wow! I can't believe it was done almost two years ago.)
That's good enough as a temporary hack, but not as a final solution. I
think we need to do the calibration similarly to how calibrate_tsc() or
calibrate_APIC_clock() do that for the i386. Specifically, we need to do
that with polling for appropriate accuracy (interrupt delivery time might
not be deterministic) and preferably before interrupts are enabled
(time_init() looks like a perfect place to do that). And of course we
need to poll against the interrupt source as it's the frequency ratio that
matters (otherwise I could e.g. just read the TURBOchannel clock frequency
as reported by the firmware for the HPT on R3k DECstations). That means
it needs to be done in platform-specific way.
I have an idea how to make an abstraction layer for this purpose and I'll
make a patch for the DECstation soon. The plan might be as follows:
1. I'll apply the patch as is (Ralf has already approved it off-list) as
the calibrate_*() backends won't disappear immediately anyway.
2. I'll provide the abstraction layer together with an example
implementation for the DECstation.
3. For 2.6 I'll add a warning about uninitialized mips_counter_frequency
and deprecation of calibrate_*() backends, so that platform maintainers
know what's going on.
4. After 2.7 starts code related to calibrate_*() will be removed and the
kernel will panic() if a HPT is found, but mips_counter_frequency is zero.
Any comments?
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
|