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;
> xnpod_wait_thread_period() - over which rt_task_wait_period() is based -
> does not loop, but rather computes the actual count of overruns by
> substracting the current time from the deadline.
...but by looping for some scenarios instead of dividing for all. Why
optimising the slow path here?
>
> Which brings us an interesting question: why does the aperiodic handler
> loop frenetically in the first place? I would be pretty interested in
> checking the TSC values returned by xnarch_get_cpu_tsc() while spinning
> inside this deadly loop...
You can already read those TSCs: each trace point got recorded with the
current TSC value, fresh from the hardware.
I rather think, also when looking at Julien's second trace, that we have
some issue with X in user-space here, probably in combination with weird
VIA hardware stalling IRQ delivery for a "few" microseconds. Let's see
if the irqbench gives similar results.
Jan
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
