`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 wheretime_adjust and time_adjust_step are zero, that's all.  It's a veryminor thing.  In fact if time_adjust is zero we could avoid theprocedure call, the subtraction and the multiplication by 1000, likethis:	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;	}> > +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 ananosecond's worth.  I took the approach of delivering the fullprecision of time_adj to the arch code (i.e. including the 12 bits tothe right of the binary point), rather than truncating it to wholenanoseconds and then having to vary it by +/- 1 nanosecond each tick.Basically time_phase is just accumulating the fraction of a nanosecondthat we haven't been able to add onto xtime yet.  The effect of thatis that some ticks are 1 nanosecond longer or shorter than others,depending on the fractional part of time_adj.  I set the factor andoffset that I use in the lockless gettimeofday to take into accountthe whole time_adj value, including the fractional part.  That way Idon't have to change the factor and offset every tick, but only whentime_adj changes (or when the adjtime adjustment changes, of course).The possible +/- 1 nanosecond difference is smaller than theresolution of the timebase register, and way smaller than the time ittakes to do a gettimeofday and compare it with xtime, so it can beignored.Paul.-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/`