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

john stultz
2004-09-03T02:18:18Z

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