Re: [RFC][PATCH] new timeofday i386 hooks (v.A0)

[john stultz]

On Thu, 2004-09-02 at 18:44, George Anzinger wrote:
> john stultz wrote:
> > +void sync_persistant_clock(struct timespec ts)
> > +{
> > +	/*
> > +	 * If we have an externally synchronized Linux clock, then update
> > +	 * CMOS clock accordingly every ~11 minutes. Set_rtc_mmss() has to be
> > +	 * called as close as possible to 500 ms before the new second starts.
> > +	 */
> > +	if (ts.tv_sec > last_rtc_update + 660 &&
> > +	    (ts.tv_nsec / 1000)
> > +			>= USEC_AFTER - ((unsigned) TICK_SIZE) / 2 &&
> > +	    (ts.tv_nsec / 1000)
> > +			<= USEC_BEFORE + ((unsigned) TICK_SIZE) / 2) {
> > +		/* horrible...FIXME */
> > +		if (efi_enabled) {
> > +	 		if (efi_set_rtc_mmss(ts.tv_sec) == 0)
> > +				last_rtc_update = ts.tv_sec;
> > +			else
> > +				last_rtc_update = ts.tv_sec - 600;
> > +		} else if (set_rtc_mmss(ts.tv_sec) == 0)
> > +			last_rtc_update = ts.tv_sec;
> > +		else
> > +			last_rtc_update = ts.tv_sec - 600; /* do it again in 60 s */
> > +	}
> > +
> I have wondered, and continue to do so, why this is not a timer driven function. 
>   It just seems silly to check this every interrupt when we have low overhead 
> timers for just this sort of thing.
> 
> I wonder about the load calc in the same way...

The really cool thing is: with the new infrastructure separating the
timeofday code and the timer code, we can make timeofday_interrupt_hook
be called from a soft-timer! We don't have to do the accounting every
interrupt, but just frequently enough that the time sources don't
overflow!

> Now, the question is how do you hook up the timer list.  We MUST be able to 
> start a timer that will run for several min to hours and have it expire such 
> that the wall time difference is "really" close to what was requested.  This 
> requires some "lock up" between the wall clock and the timer subsystem.
> 
> What are your thoughts here?

Well, looking way down the road, once timeofday is independent from the
soft-timer code, we can invert the dependency so the soft-timer code
uses the high-res timeofday code instead of jiffies for determining if a
timer has expired. That would allow for more precise timer intervals to
be set, without worry of how it might affect timekeeping.

Easier said then done, I agree, but this change does allow for these
sorts of thing to be attempted. 

My favorite benefit is that lost-ticks caused by bad drivers become a
timer/scheduler latency issue rather then a timeofday is broken issue :)

Yay!

Thanks again, George!
-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/