Q: x86 interrupt arrival after cli
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.
Signature · 1 line
WebSig: http://www.jukie.net/~bart/sig/
Quoted 5 lines
Quick question for the x86 gurus:
If a hardware interrupt arrives within a
spin_lock_irqsave&spin_unlock_irqrestorewill 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.
Quoted 2 lines · On Thu, 16 May 2002 14:32:19 +0100 (BST) Alan Cox <[email protected]>…
Quoted 2 lines
Quick question for the x86 gurus:
Not a real x86 guru :-)
Quoted 6 lines
Quoted 3 lines
If a hardware interrupt arrives within a
spin_lock_irqsave&spin_unlock_irqrestorewill the interrupt handler associated with said interrupt be called immediately after the spinlock is released? =20It 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 :-)
Signature · 3 lines
Cheers, Stephen Rothwell [email protected] http://www.canb.auug.org.au/~sfr/
Quoted 9 lines · Bart Trojanowski
[-- 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_irqrestorewill 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
Signature · 2 lines
It is better to keep your mouth shut and be thought a fool,
than to open it and remove all doubt.Quoted 11 lines · Ion Badulescu
Quoted 9 lines · Bart Trojanowski
[-- 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_irqrestorewill 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.
Quoted 8 lines
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.
Quoted 13 lines · Richard B. Johnson
<--- 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
Quoted 1 line
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.
Signature · 3 lines
bill davidsen <[email protected]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979.