[Xenomai-help] rt_intr_wait takes 10ms

[Xenomai-help] rt_intr_wait takes 10ms

[Tomas Kalibera]

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

Re: [Xenomai-help] rt_intr_wait takes 10ms

[Gilles Chanteperdrix]

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.