On Fri, 2006-10-20 at 12:33 +0200, Jan Kiszka wrote:
> While digging into a latency issue with multiple IRQs pending (patch
> will likely follow soon), I noticed that the replay order on x86 is the
> inverse of the hardware order. Instead of iterating from lowest IRQ
> number to highest, ipipe currently starts with the highest one. The
> attached patch fixes this.
>
We want to give a priority boost to virtual IRQs over real ones, at
least for the root domain. Since virqs are high-numbered, bsrl has been
used on purpose to scan the pending IRQ mask. Additionally, low-numbered
IRQs have higher priority only if you consider the ISA ones as managed
by the 8259. Bringing the APIC into the picture, the APIC-based timer
IRQ used by RTOSes over Adeos is a high-numbered one.
> Jan
> plain text document attachment (fix-x86-irq-replay-order.patch)
> Index: linux-2.6.17.13/include/asm-i386/ipipe.h
> ===================================================================
> --- linux-2.6.17.13.orig/include/asm-i386/ipipe.h
> +++ linux-2.6.17.13/include/asm-i386/ipipe.h
> @@ -242,8 +242,7 @@ extern int __ipipe_tick_irq;
>
> static inline unsigned long __ipipe_ffnz(unsigned long ul)
> {
> - __asm__("bsrl %1, %0":"=r"(ul)
> - : "r"(ul));
> + __asm__("bsfl %1, %0":"=r"(ul):"r"(ul));
> return ul;
> }
>
> _______________________________________________
> Adeos-main mailing list
> [email protected]
> https://mail.gna.org/listinfo/adeos-main
--
Philippe.
_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main
