[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Interrupt Latency on PPC (was Re: Interrupt latency problems onMPC860)
- Date: Fri, 16 Nov 2001 11:51:44 -0800
- From: strauman at SLAC.Stanford.EDU (Till Straumann)
- Subject: Interrupt Latency on PPC (was Re: Interrupt latency problems onMPC860)
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...