Re: [RFC][PATCH] new timeofday core subsystem (v.A0)

john stultz
2004-09-09T19:16:00Z

On Wed, 2004-09-08 at 21:31, George Anzinger wrote:
> john stultz wrote:
> > I'm not sure about the busy wait bit, but yes, at some point I'd like to
> > see the timer subsystem use the timeofday subsystem instead of jiffies
> > for its timekeeping.
> >
> Yes, I think this is the way we want to go. Here are the "rubs" I see:
>
> a.) resolution. If you don't put a limit on this you will invite timer storms.
> Currently, by useing 1/HZ resolution, all timer "line up" on ticks and reduce
> the interrupt overhead that would occure if we actually tried to give "exactly"
> what was asked for. This is a matter of math and can be handled (assuming we
> resist the urge to go shopping :))

Well, basically we have the same resolution as we do today. Right now
you specify the time in jiffies which has different resolutions
depending on configuration, so I'm not sure I see the problem. I mean, I
guess someone could be off put when they ask for a 1 ns expiration time
and it returns in 1 ms, but I thought timers followed sleep() semantics,
so it shouldn't be that much of an issue.

> b.) For those platforms with repeating timers that can not "hit" our desired
> resolution (i.e. 1/HZ) there is an additional overhead to program the timer each
> interrupt. In principle we do this in the HRT patch, but there we only do it
> for high resolution timers, which we assume are rather rare. It is good to have
> a low res timer that is also accurate. Even better if we can keep the overhead
> low by not having to reprogram a timer each tick.
>
> In the ideal world we would have a hardware repeating timer that is reasonably
> accurate (we might want to correct it every second or so) to generate the low
> res timing interrupts and a high res timer that we can program quickly for high
> resolution interrupts.

Even in this case, inaccurate hardware timers can only cause a single
tick jitter. The current problem we're seeing is that the timer
inaccuracy accumulates, so if we're 1% off, a sleep(600) returns 6
seconds late. Using the time source instead of jiffies for expiration
would avoid the accumulation, so we'd be at most a single tick late.

Or is the problem more subtle?

thanks
-john