Interrupt Latency on PPC (was Re: Interrupt latency problems onMPC860)

[Till Straumann]

VALETTE Eric wrote:

> Till Straumann wrote:
>
> > RTEMS BSP implementation details:
> >
> >   1) BSP re-enables IRQs during user ISR call [both for
> >       external interrupts and for the timer tick (decrementer)].
> >
> >   2) external interrupts are all at priority 8, my timer uses
> >       priority 13 which is higher [and hence should nest into
> >       any other ISR].
>
> Correct :-)
>
> > The maximal latency observed is much worse than the average. Furthermore,
> > there was a case of high nesting level with a quite low latency. Because the
> > 'vector-hunt' and dispatching code is executed for every single interrupt, it
> >
> > shows up in the average figure which is quite fast.
> > Hence, neither the PPC hardware nor the interrupt vector-hunting/dispatching
> > code can be responsible for the worst case delays.
>
> Thanks. Spend some time trying to figure how to make it fast...

???? - I guess my point is that the dispatching code is fast enough
but that there must be interrupt-disabled sections of code somewhere
else which we should try to find.

>
>
> Just a small hint (from memory so double check) : the OpenPIC 0 interrupt (on MCP750 but probably also on
>
> your board) is the shraed irq that collect all irq generated by PC legagcy
>
> compatible hardware (read kind of 8259 interrupt controller). I choose to gave
>
> it the highest priority and then to manage legacy PC interrupt
> priorities using the mask provided by the 8259 (like on PC). If you
> lower the OpenPic 0 interrupt priority, all non PCI device will may have
> a higher priority than the PC legacy devices.

I had thought about that, but it seems that the 8259 hooks into the OpenPIC
also at priority 8 (shared/openpic/openpic.c).

>
>
> Besides and this is a side comment from your original mail nesting level
> can be only 2 and interrupt latency quasy infinite...
>

Eric - I'm sorry, I don't understand what you mean here. Again, my conclusion
was that if there are cases with a quite high nesting level showing good/fast
performance, the IRQ dispatching code can _not_ be responsible for the
occasionally experienced high latencies.

I guess I already found one real-time killer: the combination of telnetd's PTY
driver with termios...

-- Till