On Tue, 2005-08-23 at 13:30 +0200, Roman Zippel wrote: > Hi, > > On Mon, 22 Aug 2005, john stultz wrote: > > > The reason why we calculate the interval_length in the continuous > > timesource case is because we are not assuming anything about the > > frequency that the timekeeping_periodic_hook() is called. > > The problem with your patch is that it doesn't allow making such > assumptions. > Anyway, it's rather simple, if you want to update the time asynchronously: > > cycle_offset = get_cycles() - last_update; > > while (cycle_offset >= update_cycles) { > cycle_offset -= update_cycles; > last_update += update_cycles; > // at init: system_update = update_cycles * mult; > system_time += system_update; > xtime += [tick_nsec, time_adj]; > } > > error = system_time - (xtime.tv_nsec << shift); > > if (abs(error) > update_cycles/2) { > mult_adj = (error +- update_cycles/2) / update_cycles; > mult += mult_adj; > system_update += mult_adj * update_cycles; > system_time -= mult_adj * cycle_offset; > error -= mult_adj * cycle_offset; > } > > if (xtime.tv_nsec + (error >> shift) > NSEC_PER_SEC) { > system_time -= NSEC_PER_SEC << shift; > second_overflow(); > }
AH! Ok, now I get it. Forgive me for being so dense, but code is just so much more concrete and understandable. Let me take a swing at integrating some of this idea into my code and then we can go around again. :) > The last one may become a bit of a challenge to keep as much as possible > code common without abusing the preprocessor too much. In any case some > functions will differ completely anyway, especially gettimeofday will be > optimized differently depending on the arch/clock requirements, OTOH > introducing a common gettimeofday (that would even require a 64bit > divide) would be a huge mistake. I'd always want to allow for arch specific implementations, but there are many cases where the code is doing the exact same thing, so I'd like to at least consolidate those users. No divides in the hot-path are necessary. Thanks again for the review and patience. I really do appreciate it. thanks -john - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/