Messages in this thread | | | Subject | Re: [PATCH v2] Provide an interface for getting the current tick length | From | john stultz <> | Date | Thu, 16 Feb 2006 16:53:02 -0800 |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |