lkml.org 
[lkml]   [2004]   [Sep]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC][PATCH] new timeofday i386 hooks (v.A0)
From
Date
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:05    [W:0.163 / U:21.184 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site