Re: [patch 00/21] hrtimer - High-resolution timer subsystem

[Steven Rostedt]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/