I’ve worked on CPUs that have levels, and those that have pure masks. The X86 APIC
implementation uses the upper 4 bits of the 8 bit vector as the interrupt level. Raising the IRQL
on a X86, at least with an APIC, means basically taking the IRQL, sifting it left 4, and assigning that
value to some local APIC register. So for the X86, there is definitely a level implemented in hardware.
Its not just an OS concept.
Your “service the queue” interrupt is an interesting idea. Implementation in my case (inside a SCSI miniport)
is a bit problematic, but the hardware fits your model. With your proposal, I’d only get an interrupt
on the transition of the queue from empty to not empty. Under saturation, the ISR overhead would go to
zero. I’m always looking for algorithms where the overhead per operation goes down as the demand increases.
Thanks,
-DH
----- Original Message -----
From: “Moreira, Alberto”
To: “NT Developers Interest List”
Sent: Wednesday, January 02, 2002 10:52 AM
Subject: [ntdev] RE: ISR Latency question
> The hardware doesn’t know about IRQLs, this is an OS invention. As far as
> the hw goes, your interrupt is either masked or disabled, or it is not. But
> you can probably implement what you want, we used to call it “interrupt
> tabling” in the old Sperry 418 series. Your interrupt vector points to your
> own interrupt handler, which enqueues the interrupt, does a minimum level of
> hardware handshake, and goes away. In parallel, you have your own thread
> dequeueing those interrupts and handling them appropriately. The 418 III did
> it in hardware, mind you, and the Sperry DCP had hardware queues, interrupts
> happened in the peripheral processors and there was no such a thing as a
> peripheral interrupting the CPU. Alas, they don’t make them like that
> anymore ! But then, isn’t that what a DPC is supposed to achieve ? You get
> an interrupt, you use your ISR to enqueue it and to clear your hardware, and
> schedule a DPC to handle the queue later on. If you (heresy!) run your
> interrupt on a trap gate instead of on an interrupt gate, you are guaranteed
> that nobody’s going to interrupt you, although of course you may still see
> your interrupt routine running concurrently on more than one processor.
>
> Unless of course your peripheral can wait until the DPC is scheduled to
> resume interrupting. You can try waiting to re-enabling interrupts until
> you’re well inside your DPC, and see if you can still handle things within
> an acceptable response time. I personally still believe the best way to
> handle this is to have a queue between peripheral and processor: the
> peripheral handles the hardware device, the queue buffers stuff between
> peripheral and processor, and a processor interrupt is a signal to service
> the queue, not to service the device.
>
>
> Alberto.
>
>
>
> -----Original Message-----
> From: Dave Harvey [mailto:xxxxx@syssoftsol.com]
> Sent: Saturday, December 29, 2001 4:39 PM
> To: NT Developers Interest List
> Subject: [ntdev] RE: ISR Latency question
>
>
>
> The other thing that would be quite valuable would be to make these devices
> interrupt at DISPATCH_LEVEL, so that they would not
> interrupt DPCs that are currently running. Is it possible to do this on
> X86 hardware? If so, would changing the HAL for
> this be feasible? If the DPC is running, there is not much point in having
> the ISR run and queue something for the DPC. In my
> case, such a change would significantly reduce the total number of
> interrupts, amortizing the ISR overhead across more
> operations.
>
> The device has a timer where you can program it to not interrupt until some
> time quantum has elapsed, allowing multiple events
> to collect and generate one interrupt, and dramatically improving
> throughput. However, enabling time delay also increases
> response time when lightly loaded (to an unacceptable level).
>
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@syssoftsol.com
> To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com
—
You are currently subscribed to ntdev as: $subst(‘Recip.EmailAddr’)
To unsubscribe send a blank email to leave-ntdev-$subst(‘Recip.MemberIDChar’)@lists.osr.com