Tomas Kalibera wrote:
>
> Hi,
>
> I've measured interrupt latencies using irqbench and extended it a bit
> to measure also latencies of a user space task that uses "rt_intr_wait",
> as opposed to the specialized ioctl call used presently by the benchmark.
>
> I found out that when the call to rt_intr_wait does not block (there is
> already an interrupt pending), the latency is nice, i.e. 20us. However,
> when rt_intr_wait blocks, the latency is 10ms (the whole quantum).
>
> I thought that once the interrupt arrives and the kernel space header
> signals the interrupt, the Xenomai scheduler should be invoked and
> should preempt any presently running thread and immediately wake up the
> thread blocked in rt_intr_wait. Is this correct ?
>
> The thread blocked in rt_intr_wait had maximum priority (99) and was in
> primary mode.
>
> Interestingly, when I run the original version of the irqbench
> benchmark, even the user space version (-t 0, default) that waits for
> the interrupt using the specialized ioctl call, had nice latencies about
> 20us. Any ideas why the rt_intr_wait does not behave equally well ?
Did you check the interrupts count returned by rt_intr_wait ? What else
do you do in the loop calling rt_intr_wait ? Do not you use special
features such as I_NO_AUTOENA ?
--
Gilles.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
