Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>  > Philippe Gerum wrote:
>  > > On Sat, 2006-07-29 at 16:20 +0200, Jan Kiszka wrote:
>  > >>>> :|func        6   xnintr_clock_handler (__ipipe_dispatch_wired)
>  > >>>> :|func        6   xnintr_irq_handler (xnintr_clock_handler)
>  > >>>> :|func        7   xnpod_announce_tick (xnintr_irq_handler)
>  > >>>> :|func        8+  xntimer_do_tick_aperiodic (xnpod_announce_tick)
>  > >>>> :|func        9   xnthread_periodic_handler (xntimer_do_tick_aperiodic)
>  > >>>> :|func       10   xnpod_resume_thread (xnthread_periodic_handler)
>  > >>>> :|[21559]    11+  xnpod_resume_thread (xnthread_periodic_handler)
>  > >>>> :|func       13+  xnthread_periodic_handler (xntimer_do_tick_aperiodic)
>  > >> ...
>  > >>
>  > >>>> :|func      363+  xnthread_periodic_handler (xntimer_do_tick_aperiodic)
>  > >> That are a lot of overruns. Haven't counted, but it should be one
>  > >> xnthread_periodic_handler per missed 100 us period (20000 / 100 = 200!).
>  > >> [BTW, I think we should handle even this failure scenario without
>  > >> looping.
>  > > 
>  > > We need to loop in the aperiodic handler in order to catch timers that
>  > > could have elapsed while processing the current tick. However,
>  > 
>  > No, that was not what I meant. I know that we need the timer loop. But I
>  > was thinking of something like this for the tick handler's error path:
>  > 
>  > if (unlikely((timer.date += timer.interval) < now))
>  > 	timer.date = now + timer.interval -
>  > 		(now - timer.date) % timer.interval;
> 
> Actually,
> 
> while (timer.date < now)
>        timer.date += timer.interval
> 
> cost much less cycles in the normal/fast case than going through a
> division... 
> 

Yeah, most probably the right way for the timer IRQ. If we have to loop
here significantly often, then we already had a much too long IRQ-off
period and are toasted anyway.

Jan