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 ? Thanks, Tomas _______________________________________________ Xenomai-help mailing list [email protected] https://mail.gna.org/listinfo/xenomai-help
