Re: [RFC][PATCH] new timeofday arch specific hooks (v. A2)

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

On Wed, 2005-01-26 at 10:53 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2005-01-25 at 15:09 -0800, john stultz wrote:
> 
> > The performance is a concern, and right now there are issues (ntp_scale
> > being the top of the list) however I hope they can be resolved. Looking
> > at ppc64's do_gettimeofday() vs this implementation there we do have
> > more overhead, but maybe you could suggest how we can avoid some of it?
> 
> I would suggest reclaculating the scale factor and offset for ntp
> adjustement regulary from the timer tick or so, not on each gettimeofday
> call.

Agreed. I'll get something like this done for the next release.


> Also, I have some updates to the ppc64 implementation where I regulary
> update the pre-scale offset into the post-scale one so that the
> timebase-prescale substraction always gives a 32 bits number. I do that
> so my fast userland gettimeofday can be implemented more easily and more
> efficiently for 32 bits processes. I yet have to check how I can hook
> those things into your new scheme.

Hmm. In my code, I move the interval delta (similar to your pre-scale
offset) to system_time (seems to be equivalent to the post-scale) at
each call to timeofday_interrupt_hook(). So while 64 bits are normally
used, you could probably get away doing the interval delta calculations
in 32bits if your timesource frequency isn't too large. This would only
be done in the arch-specific 32bit vsyscall code, right?

> > I still want to support vsyscall gettimeofday, although it does have to
> > be done on an arch-by-arch basis. It's likely the systemcfg data
> > structure can still be generated and exported. I'll look into it and see
> > what can be done.
> 
> Well, since it only contains the prescale and postscale offsets and the
> scaling value, it only needs to be updated when they change, so a hook
> here would be fine.

Great, thats what I was hoping.

thanks
-john