On Wed, 2005-12-14 at 23:30 +0100, Thomas Gleixner wrote:
> >
> > I don't think that's enough (unless I missed something). Steven maybe
> > explained it better than I did in
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=113047529313935
>
> Steven said:
>
> > 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
>
> Again, I'm not able to find the problem.
>
> while(timers_pending()) {
> timer = getnext_timer();
> if (timer->expires > now)
> break;
> execute_callback();
> }
>
> Please elaborate how the timer can expire early.
Actually Thomas, the above code doesn't handle it correctly, although,
the code you have in hrtimer.c does. Here you say ">" where it should
be ">=", otherwise you can have the affect that I explained in the
reference that Roman stated.
Although run_hrtimer_queue is still correct, I think you might want to
change the hrtimer_forward. It has a ">" where it should be ">=".
-- Steve
-
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]
