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

[VALETTE Eric]

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


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.

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




-- 
    __
   /  `                          Eric Valette - Canon CRF
  /--   __  o _.                 Product Dev. Group Software Team Leader
(___, / (_(_(__                 Rue de la touche lambert
                                 35517 Cesson-Sevigne  Cedex
                                 FRANCE
Tel: +33 (0)2 99 87 68 91       Fax: +33 (0)2 99 84 11 30
E-mail: valette at crf.canon.fr    http://www.crf.canon.fr