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

[Roman Zippel]

Hi,

On Fri, 28 Oct 2005, Steven Rostedt wrote:

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

Thanks for the effort. :-) I know I'm sometimes a bit difficult to 
understand, which makes it easier to simply flame me for a silly mistake.

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

Yes.

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

You're correct. I missed that comparison, so if clock resolution and timer 
resolution are equal, this indeed works.
It still goes wrong if the resolutions are different. get_time() normally 
wouldn't use jiffies but xtime. Thomas uses a fixed resolution, but xtime 
updates are not constant. On my machine here with HZ=250 the resolution 
would be 4000000ns, but xtime is updated by about 4000150ns every tick. 
This means the timer value is rounded to full 4ms, but this is not enough 
to get it past the next tick.
In the other more common case, where clock resolution is smaller than the 
timer resolution, this means the delay may be larger than really 
necessary.

bye, Roman
-
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/