Re: [RFC][PATCH] use cycle_t instead of u64 in struct time_interpolator

[john stultz <johnstul@us.ibm.com>]

On Wed, 2007-01-03 at 19:36 +0100, Helge Deller wrote:
> On Wed Jan 3 2007, Christoph Lameter wrote:
> > On Tue, 2 Jan 2007, Helge Deller wrote:
> >
> > > As far as I could see, this patch does not change anything for the
> > > existing architectures which use this framework (IA64 and SPARC64),
> > > since "cycles_t" is defined there as unsigned 64bit-integer anyway
> > > (which then makes this patch a no-change for them).
> >
> > The 64bit nature of some entities was so far necessary to get the
> > proper accuracy of interpolation. Maybe it can be made to work with 32 bit
> > entities. The macro GET_TI_SECS must work correctly and the less bits are
> > specified in shift the less self-tuning accuracy you will get.
> 
> Yes, it was easily possible to make it 32bit-ready without loosing the accuracy.
> 
> Nevertheless, in the meantime John Stultz pointed me to the CONFIG_GENERIC_TIME framework,  and I implemented it that way:
> http://git.parisc-linux.org/?p=linux-2.6.git;a=commit;h=b6de83b58b8b07f057deacdef8a95b6c32d1c4e6

This looks pretty good, although setting the rating to 200 for a
clocksource you don't want to use seems a bit high (there's a rough
rating scale in clocksource.h). Zero is probably what you want to use
there.

> http://git.parisc-linux.org/?p=linux-2.6.git;a=commit;h=f70a979c843e4610edfb2a316648fe8ae8718f69

This looks to be correct, although as the clocksource infrastructure
evolves it looks like we'll be removing the update_callback code in the
future. So this is fine for now, but will probably need a reevaluation
at some point.

Also to avoid jumping between clocksources, I'd keep the initial
disqualification that occurs before you register the clocksource
(otherwise it will be used for one tick, then be disqualified and you're
back to jiffies).

thanks
-john