Re: [RFC - 0/9] Generic timekeeping subsystem (v. B5)

[john stultz]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/