Re: [PATCH v2] Provide an interface for getting the current tick length

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

On Fri, 2006-02-17 at 11:43 +1100, Paul Mackerras wrote:
> john stultz writes:
> 
> > > +	if (time_adjust_step)
> > >  		/* Reduce by this step the amount of time left  */
> > >  		time_adjust -= time_adjust_step;
> > 
> > Does the if statement really buy you anything here? 
> 
> Well, just avoiding dirtying a cache line in the common case where
> time_adjust and time_adjust_step are zero, that's all.  It's a very
> minor thing.  In fact if time_adjust is zero we could avoid the
> procedure call, the subtraction and the multiplication by 1000, like
> this:
> 
> 	delta_nsec = tick_nsec;
> 	if (time_adjust) {
> 		time_adjust_step = adjtime_adjustment();
> 		/* Reduce by this step the amount of time left  */
> 		time_adjust -= time_adjust_step;
> 		delta_nsec += time_adjust_step * 1000;
> 	}

Yea, I was thinking if you weren't going to do it for the mult, why
bother on the subtract. Either way, I'm not too picky, it should just be
consistent.

> > > +u64 current_tick_length(void)
> > > +{
> > > +	long delta_nsec;
> > > +
> > > +	delta_nsec = tick_nsec + adjtime_adjustment() * 1000;
> > > +	return ((u64) delta_nsec << (SHIFT_SCALE - 10)) + time_adj;
> > > +}
> > 
> > You've got time_adj here, but you're not using what's been accumulated
> > in time_phase, is that really ok?
> 
> Yes.
> 
> What's been accumulated in time_phase is always less than a
> nanosecond's worth.  I took the approach of delivering the full
> precision of time_adj to the arch code (i.e. including the 12 bits to
> the right of the binary point), rather than truncating it to whole
> nanoseconds and then having to vary it by +/- 1 nanosecond each tick.

So you're accumulating it yourself in the arch code? That's fine, I just
wanted to be sure.

Acked-by: john stultz <johnstul@us.ibm.com>

thanks
-john