Re: [Xenomai] interrupt service

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On Thu, Feb 26, 2015 at 02:25:13PM -0500, Lowell Gilbert wrote:
> 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.

Consuming all the time for running ISRs is not normal for OSes like
Linux and Xenomai. Being able to run the ISR in less than 10us does
not mean that there is some time left for the rest of the system;
there is quite some code executed around the ISR, and at this
frequency it stops being negligible. Linux at least needs to run
from time to time for time keeping. If you want to execute something
with this frequency, maybe you could consider using an FIQ. FIQs
have a lower overhead.

So, to be clear, does the ISR run on CPU0 and the thread doing the
reads run on CPU1? If no, does it work if you do it that way? To
know whether the problem comes from the interrupt consuming all the
available time, simply create a periodic task, in addition to the
ISR, with a high priority, and see if it executes from time to time
to increment a counter. If it does not execute, then we have a proof
that the ISR is not letting anything else run.

Another problem may be in handling the /proc/xenomai/affinity, so
could you try without using it? Same for isolcpus. If the ISR runs
on cpu0 and the tasks run on cpu1, an IPI should be sent in
__xnpod_schedule to wake up the task blocked in read, you can check
whether the IPI is sent by using ipipe_trace_special for instance
and checking the tracer trace.

> 
> >> 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.

No, irqbench is not use as commonly as the latency test. timerbench,
used by the latency test, uses RTDM events.

-- 
					    Gilles.