Q: x86 interrupt arrival after cli

Q: x86 interrupt arrival after cli

[Bart Trojanowski]

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

Quick question for the x86 gurus:

If a hardware interrupt arrives within a spin_lock_irqsave &
spin_unlock_irqrestore will the interrupt handler associated with said
interrupt be called immediately after the spinlock is released?  

I am interested in any delays, even those less then a jiffie.

Cheers,
Bart.

-- 
				WebSig: http://www.jukie.net/~bart/sig/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Q: x86 interrupt arrival after cli

[Alan Cox]

> Quick question for the x86 gurus:
> 
> If a hardware interrupt arrives within a spin_lock_irqsave &
> spin_unlock_irqrestore will the interrupt handler associated with said
> interrupt be called immediately after the spinlock is released? =20

It will be called as soon as the cpu hardware gets around to it - which 
should be just after the irq mask flag is cleared. 

Re: Q: x86 interrupt arrival after cli

[Stephen Rothwell]

On Thu, 16 May 2002 14:32:19 +0100 (BST) Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
>
> > Quick question for the x86 gurus:

Not a real x86 guru :-)

> > If a hardware interrupt arrives within a spin_lock_irqsave &
> > spin_unlock_irqrestore will the interrupt handler associated with said
> > interrupt be called immediately after the spinlock is released? =20
> 
> It will be called as soon as the cpu hardware gets around to it - which 
> should be just after the irq mask flag is cleared.

If memory serves (and Intel hasn't changed things) you get to
at least start the execution of the next instruction which means,
for most instructions, the interrupt will be delivered after the
instruction after the instruction unmasks the irqs.

Actually, this makes no difference at the C level :-)
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

Re: Q: x86 interrupt arrival after cli

[Ion Badulescu]

On Wed, 15 May 2002 20:27:20 -0400, Bart Trojanowski <bart@jukie.net> wrote:
> [-- text/plain, encoding quoted-printable, 14 lines --]
> 
> Quick question for the x86 gurus:
> 
> If a hardware interrupt arrives within a spin_lock_irqsave &
> spin_unlock_irqrestore will the interrupt handler associated with said
> interrupt be called immediately after the spinlock is released?  
> 
> I am interested in any delays, even those less then a jiffie.

The interrupt will occur when the instruction after the "sti" finishes.
That's a one assembler instruction delay, i.e. a few clock cycles.

*Which* interrupt will be serviced first, however, depends on how 
many interrupt sources you have active and on the IRQ prioritization.

Ion

-- 
  It is better to keep your mouth shut and be thought a fool,
            than to open it and remove all doubt.

Re: Q: x86 interrupt arrival after cli

[Richard B. Johnson]

On Thu, 16 May 2002, Ion Badulescu wrote:

> On Wed, 15 May 2002 20:27:20 -0400, Bart Trojanowski <bart@jukie.net> wrote:
> > [-- text/plain, encoding quoted-printable, 14 lines --]
> > 
> > Quick question for the x86 gurus:
> > 
> > If a hardware interrupt arrives within a spin_lock_irqsave &
> > spin_unlock_irqrestore will the interrupt handler associated with said
> > interrupt be called immediately after the spinlock is released?  
> > 
> > I am interested in any delays, even those less then a jiffie.
> 
> The interrupt will occur when the instruction after the "sti" finishes.
> That's a one assembler instruction delay, i.e. a few clock cycles.
> 
> *Which* interrupt will be serviced first, however, depends on how 
> many interrupt sources you have active and on the IRQ prioritization.
> 
> Ion
> 
Correct. And the priority for the Intel/IBM class machine is:

<--- HIGHEST    -------------------     LOWEST ---->

IRQ0, 1, 8, 9, 10, 11, 12, 13, 14, 15, 3, 4, 5, 6, 7
   |  |  |                             |  |  |  |  |_ printer
   |  |  |                             |  |  |  |____ Floppy
   |  |  |                             |  |  |_______ Fixed disk
   |  |  |                             |  |__________ Serial 0
   |  |  |                             |_____________ Serial 1
   |  |  |
   |  |  |___________ IRQ2->IRQ8 cascade  RTC
   |  |______________ Keyboard
   |_________________ PIT channel 0

IFF the IO-APIC is programmed to emulate the old dual controllers.

Answering; 
"I am interested in any delays, even those less then a jiffie."

Any interrupt request that becomes active during your ISR, that
has a higher priority, will be serviced before your ISR gets
another chance to be serviced.

As far as normal delays are concerned, one can make a simple
interrupt routine that just bumps a counter, that works off
from IRQ7 (the printer port), with a 400MHz machine (obsolete now),
I could do 80,000 interrupts per second without missing any.

This number should scale to your CPU speed quite well. FYI, this
is the lowest priority and everything else was running (network
with all its broadcast junk, etc).

As I recall, if I disconnected the network, and didn't touch the
keyboard, I could do over 150,000 interrupts per second without
missing any.


Cheers,
Dick Johnson

Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).

                 Windows-2000/Professional isn't.

Re: Q: x86 interrupt arrival after cli

[Bill Davidsen]

On Thu, 16 May 2002, Richard B. Johnson wrote:


> <--- HIGHEST    -------------------     LOWEST ---->
> 
> IRQ0, 1, 8, 9, 10, 11, 12, 13, 14, 15, 3, 4, 5, 6, 7
>    |  |  |                             |  |  |  |  |_ printer
>    |  |  |                             |  |  |  |____ Floppy
>    |  |  |                             |  |  |_______ Fixed disk
>    |  |  |                             |  |__________ Serial 0
>    |  |  |                             |_____________ Serial 1
>    |  |  |
>    |  |  |___________ IRQ2->IRQ8 cascade  RTC
>    |  |______________ Keyboard
>    |_________________ PIT channel 0
> 
> IFF the IO-APIC is programmed to emulate the old dual controllers.

Yes, and if anyone missed this subtle point, the priorities are
programmable! There have been patches, particularly back in 2.1.120+, to
diddle priority to make marginal system work, or move the failures to
something with more robust retries.

Nice diagram, I'm taking it to a meeting (credited to you of course) where
I will be talking about interrupt use on parallel ports.

-- 
bill davidsen <davidsen@tmr.com>
  CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.