Re: [PATCH] ktimers subsystem 2.6.14-rc2-kt5

[Steven Rostedt]

On Thu, 2005-10-27 at 22:23 +0200, Roman Zippel wrote:

> 
> Next question would be what happens if timer and clock resolution differs? 
> For example if the clock has a resolution of 1us and the timer runs every 
> 1ms. For relative timer this would mean we can keep the error within 
> 1.001ms and for absolute timer within 1ms. Do we really have to force an 
> error larger than really necessary?
> 
> Interesting is now that Thomas doesn't take the clock resolution into 
> account at all. Let's say clock and timer resolution are 1ms (or HZ=1000). 
> If we program a normal kernel timer, we do something like this:
> 
> 	timer->expires = jiffies + 1 + usecs_to_jiffies(timeout);
> 
> Thomas does now basically this:
> 
> 	timer->expires = jiffies * res + round(timeout, res);
> 
> IOW if the clock resolution is larger than the interrupt delay, the timer 
> may expire early.

Roman, I think I know what you are trying to say here. Although it took
me several readings of what you wrote and then really just looking at
Thomas' code.

It's the old problem with:

1          2          3          4     
+----------+----------+----------+---------->>
       ^                ^
       |                |
     Start             End

Asking for 2 ms (with both clock and res the same at 1ms). We start the
clock at 1 but it really is 1.7 and we get the interrupt and return at 3
but really 3.2, so instead of receiving a wait of 2ms, we return with
3.2 - 1.7 = 1.5ms

Currently, this is not a problem when the clock is at a higher
frequency, (like the tsc).  So the base->get_time works now since the
clock is at a higher frequency, but if the get_time returned jiffies,
this would fail.  And the clock used is also much faster that the delay
it takes to get back to the calling process (which is much more than a
nanosecond today).

Is that what you were trying to say Roman?

Interesting though, I tried to force this scenario, by changing the
base->get_time to return jiffies.  I have a jitter test and ran this
several times, and I could never get it to expire early.  I even changed
HZ back to 100.

Then I looked at run_ktimer_queue.  And here we have the compare:

		timer = list_entry(base->pending.next, struct ktimer, list);
		if (ktime_cmp(now, <=, timer->expires))
			break;

So, the timer does _not_ get processed if it is after or _equal_ to the
current time.  So although the timer may go off early, the expired queue
does not get executed.  So the above example would not go off at 3.2,
but some time in the 4 category.

So the function will _not_ be executed early, although this could mean
that the timer could actually go off early (in the HRT case), but I
haven't taken a look there.  That is to say the interrupt goes off
early, not the function being executed.

-- Steve


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