Well, I teach computer architecture, so, I’d better have my act sort of
together or my students will shoot me.
We may be talking about different things: you’re looking at the processor
and the OS, I’m looking at the I/O subsystem. If the OS uses an interrupt
gate, interrupts to the processor are indeed masked, but not at the APIC,
indeed,you’re right, if I get a higher priority peripheral before the
processor’s ISR issues that STI, the APIC will still handle it and another
processor can catch it. However, if interrupts come at fast enough a pace,
they’ll back up at the peripheral because of the global latency issue. For
lower priority interrupts, the local APIC will mask them, so, issuing the
STI is not enough, the higher priority interrupt must be cleared before a
lower priority interrupt can get through.
Whether an interrupt will be lost depends entirely on the nature of the
peripheral subsystem. If my peripheral has a deadline for that interrupt to
be cleared, I will lose data unless I have buffering, and I will lose data
if the interrupt latency is larger what my traffic needs: in the end it’s an
M/M/1 queue. Point being, the issue of losing interrupts cannot be totally
solvable at processor level, it must take the nature of the particular I/O
subsystem into account. So, depending on the peripheral, it may not matter
whether the local APIC accepts a higher priority interrupt while the
processor is running with interrupts disabled ! Some interrupts are only
cleared when the ISR pokes at the peripheral, and not doing that fast enough
may lead to traffic backing up at the processor. So, when you say interrupts
won’t be lost, what you’re really saying is, the processor won’t lose any
interrupts that the APIC sees - but those are already the survivors. In the
end it’s a sequential chain: peripheral, I/O APIC, Local APIC, processor,
ISR, I/O, peripheral, and the total latency as far as the peripheral sees is
the sum of them all. Unless that latency is smaller than what the peripheral
can admit, data will be lost.
I still believe that interrupts should be very short lived things: get one,
get control into the ISR as soon as possible, let the ISR clear the
interrupt as fast as possible without being interrupted, enqueue the
interrupt and get out - let the DPC handle the rest. I believe IRQL should
be handled entirely by the APIC hardware, no need for the OS to bother
itself with. I also believe that if APICs had hardware interrupt queueing,
the net I/O throughput of the system would go up, making the machine a
better server.
-----Original Message-----
From: Jake Oshins [mailto:xxxxx@windows.microsoft.com]
Sent: Saturday, December 14, 2002 2:14 PM
To: NT Developers Interest List
Subject: [ntdev] RE: interrupt handshaking - was other crap
I’m surprised at you Alberto. As much as I disagree with your
philosophy regarding the way drivers should be written, your
understanding of processor architecture is usually dead-on.
All interrupts are masked at the processor core before the STI
instruction is issued. But the Local APIC is still accepting interrupt
messages from the I/O APICs. This means that a higher priority
interrupt will be accepted, including setting the TMR and IRR bits. As
soon at the processor issues the STI, the processor will be interrupted
by the Local APIC with that high-priority interrupt, and the Local APIC
will then set the ISR bit.
The same will happen for lower-priority interrupts, except that they
won’t be delivered to the processor until the OS writes a lower-IRQL
value into the TPR register in the Local APIC.
None will be lost. All of the examples that I have given so far have
been for level-triggered interrupts. So, to put your mind at ease, I’ll
quickly describe the protocol for edge-triggered interrupts.
When the OS receives a level-triggered interrupt, it sends the EOI after
a driver-specific ISR has claimed it, or after it hits the end of the
ISR chain. The causes the I/O APIC to re-sample the interrupt and send
another one if the line is still active.
Edge-triggered interrupts can’t work this way. So the OS sends the EOI
after raising IRQL and before issuing the STI instruction, which is
before it calls the device-specific ISR chain. That way any new edge
triggered events will be accepted at the Local APIC. Duplicate
edge-triggered interrupt events may be collapsed into a single
edge-triggered event. But that doesn’t matter because we call every ISR
on the chain every time the interrupt occurs. Your ISR may be called
when your device didn’t interrupt. But it will definitely be called if
it did interrupt.
Jake Oshins
Windows Kernel Group Interrupt Guy
This posting is provided “AS IS” with no warranties, and confers no
rights.
-----Original Message-----
Subject: RE: interrupt handshaking - was other crap
From: “Moreira, Alberto”
Date: Fri, 13 Dec 2002 10:19:06 -0500
X-Message-Number: 8
If I understand this correctly, the OS reflects the IRQL in the APIC’s
priority register. Higher priority interrupts will be masked out until
the
OS issues the sti. Lower priority interrupts will be masked out until
the OS
acknowledges the interrupt. There’s a window in there where even a
higher
IRQL interrupt won’t get through, and another window where no lower
priority
interrupts will get through. This may or may not be a problem, depending
on
the application and on the interrupt volume.
Alberto.
-----Original Message-----
From: Jake Oshins [mailto:xxxxx@windows.microsoft.com]
Sent: Thursday, December 12, 2002 11:03 PM
To: NT Developers Interest List
Subject: [ntdev] RE: interrupt handshaking - was other crap
You ask for a lot. But, in order to put this to bed, here it is.
—
You are currently subscribed to ntdev as: xxxxx@compuware.com
To unsubscribe send a blank email to %%email.unsub%%
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it.