`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, whybother on the subtract. Either way, I'm not too picky, it should just beconsistent.> > > +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 justwanted to be sure.Acked-by: john stultz <johnstul@us.ibm.com>thanks-john-To unsubscribe from this list: send the line "unsubscribe linux-kernel" inthe body of a message to majordomo@vger.kernel.orgMore majordomo info at  http://vger.kernel.org/majordomo-info.htmlPlease read the FAQ at  http://www.tux.org/lkml/`