Re: [Xenomai] interrupt service

[Lowell Gilbert <kludge@be-well.ilk.org>]

Philippe Gerum <rpm@xenomai.org> writes:

> On 02/26/2015 05:38 PM, Lowell Gilbert wrote:
> The new task will be pinned to the CPU running rtdm_task_init() by
> default, which is likely CPU0 as well.
>
> To check this, I would set the global Xenomai affinity to CPU1 before
> starting the test, so that your driver task ends up there.
>
> # echo 2 > /proc/xenomai/affinity

Yes, I initialize that already. And give "isolcpus=1" to the kernel so
that Linux will not schedule anything else on CPU1.

> At least you would have the timing IRQ and the task on a different CPU,
> leaving some cycles to the latter. This said, 10 us between timer shots
> is really too fast.

Having enough cycles for this isn't my fundamental problem. Running
everything in the ISR has no trouble keeping up with the 100kHz data
flow. The problem comes in a *non* real-time task, which is pulling data
in from an IP socket and pushing it into a queue for the real-time code
to use synchronously.

If I could run bare-metal on the second CPU, I would have done so.
The real-time behaviour is easily characterized, and the periodic work
can safely be done in 10 us even if all of the data has to be fetched
from external memory.

>> I had used a counting semaphore (to account for possibly missed
>> interrupts) in an earlier version of this code before changing it to an
>> event when I found that the semaphore didn't work. I also tried a direct
>> call to rtdm_task_unblock(), and that failed also.

> If you look at ksrc/drivers/testing/timerbench.c, you will see a typical
> use of rtdm events with ISRs, this driver is used when running
> latency -t2 for instance. I'm convinced the RTDM event API is not the issue.

I think you meant irqbench.c. And yes, I also am quite sure that the
event API is behaving fine.

I think I have two options to investigate. One is to do all of my work
in the ISR, but to somehow re-enable enough interrupts to keep CPU0
doing useful work while the ISR is running on CPU1. The other is to poll
the hardware state rather than using the interrupt.  Do you see anything
else I could do?

Thanks again.

Be well.