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

[john stultz]

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


-
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/