[Adeos-main] [PATCH] x86: revert IRQs replay order

[Adeos-main] [PATCH] x86: revert IRQs replay order

[Jan Kiszka]

[-- Attachment #1.1: Type: text/plain, Size: 316 bytes --]

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.

Jan

[-- Attachment #1.2: fix-x86-irq-replay-order.patch --]
[-- Type: text/plain, Size: 457 bytes --]

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;
 }
 

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Adeos-main] [PATCH] x86: revert IRQs replay order

[Philippe Gerum]

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
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main
-- 
Philippe.

Re: [Adeos-main] [PATCH] x86: revert IRQs replay order

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 1063 bytes --]

Philippe Gerum wrote:
> 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

Hmm, are the virtual IRQs differently numbered on blackfin? Because
there we have ffs behind __ipipe_ffnz.

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

Ok, so there is no simple way to emulate reality, thus we can simply
leave it as it is. No problem.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]

Re: [Adeos-main] [PATCH] x86: revert IRQs replay order

[Philippe Gerum]

On Fri, 2006-10-20 at 15:53 +0200, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > 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
> 
> Hmm, are the virtual IRQs differently numbered on blackfin? Because
> there we have ffs behind __ipipe_ffnz.
> 

They are not, but the priority boost for virqs is most significant on
x86, this is why I did not bothered that much for other archs, including
on the Blackfin. The point is that we want the root domain to process
virqs sent by the RTOSes running on higher domains asap, at least before
long and costly Linux interrupt handlers may run; e.g. the IDE interrupt
handler on x86 (which gets even worse if you run that in PIO mode). On
the contrary, the Linux domain handlers over Adeos/Blackfin are
threaded; only a very simple primary handler wakes up the IRQ thread, so
the worst incurred delay before processing the virqs is known, short and
limited.

> > 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.
> 
> Ok, so there is no simple way to emulate reality, thus we can simply
> leave it as it is. No problem.
> 
> Jan
> 
> _______________________________________________
> Adeos-main mailing list
> Adeos-main@domain.hid
> https://mail.gna.org/listinfo/adeos-main
-- 
Philippe.