[ag-automation] Adding OSADL patch to 2.6.33.7 increases latency and CPU usage?

Grant Edwards grant.b.edwards at gmail.com
Thu May 10 01:27:41 CEST 2012


On Thu, May 10, 2012 at 12:56:40AM +0200, Carsten Emde wrote:
> Grant,
> 
> >> The solution is user-space real-time programming using portable and
> >> standardized POSIX calls. This is what PREEMPT_RT is made for. Please
> >> repeat your tests in user space with and without PREEMPT_RT
> > I can't repeat my tests in user space.  I'm testing how long it takes
> > a device driver ISR in the kernel to run.  I've got a piece of
> > hardware connected to the IRQ0 pin that needs to be serviced by its
> > device driver within X microseconds of an interrupt that it produces
> > by asserting the signal on the IRQ0 pin.

> If X is, in fact, a single-digit number, then you probably want to use 
> an FPGA or similar for your project.

X is somewhere around 20.  The really annoying thing is that the
"thing" that requires its interrupt serviced so fast is a blob of IP
in an FPGA.  The blob asserts an IRQ line, and I have to toggle a bit
in a register inside that same blob within 25us (5 of 25 is already
allocated to another bit of intervening hardware).  Why somebody
couldn't spend a few gates and do that in the FPGA itself is beyond
me.  I can't mention who's responsible for that chumk of IP (sometimes
I wonder if that's what NDA's are really for).

> Yes, indeed. However, the concept of doing real-time work in the ISR
> is pretty much related to old-school CPUs such as Motorola's 68xxx
> and similar. They have prioritized interrupts and, more importantly, 
> vectorized interrupts with a vector base register. This ensures that
> the CPU can dereference to the ISR within a couple of instructions.

Ah, the good old days. :)  The Z80 and Z8000 worked like that too:
a separate vector for every interupt source.  Assert an interrupt
signal and 4 bus cycles later the ISR is running.

It's all becoming a bit more clear now that I've stumbled on the whole
"IRQ thread" thing (which was causing my increased latencies).
Specifying the IRQF_NODELAY flag gets the average IRQs back down where
they started.

-- 
Grant


More information about the ag-automation mailing list