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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
