Higer IRQL interrupt can preempt other lower IRQL interrupt?

Discussion in 'Windows Vista Drivers' started by Daniel, Sep 15, 2003.

  1. Daniel

    Daniel Guest

    Hi,
    A basic question just to confirm a point:
    In Windows, Is It true that higer IRQL interrupt can
    preempt other interrupt with lower IRQL and all the
    interrupts with IRQL equal to or below current IRQL will
    be masked and wait until they get an opportunity?

    Thanks,

    Daniel
     
    Daniel, Sep 15, 2003
    #1
    1. Advertisements

  2. Daniel

    Walter Oney Guest

    Yep.
     
    Walter Oney, Sep 15, 2003
    #2
    1. Advertisements

  3. Seeing how this prioritizing of devices sounds like a nice feature, is
    there any good way that you can request to have a "higher" or "lower"
    interrupt IRQL? For example it might be good for my sound card to have a
    higher IRQL than my network card so intense network traffic no longer
    causes break-up of sounds playing?

    Andreas
     
    Andreas Hansson, Sep 15, 2003
    #3
  4. You have to be carefull here. We have a software interrupt
    thats below DISPATCHER_LEVEL so you can get context
    swapped even though you are running above
    PASSIVE_LEVEL. The level in question is APC_LEVEL.
    This makes this s/w interrupt level sort of thread local. You
    block APC's by raising to this level only in the current thread
    because you could be context swapped away from the
    thread to a thread running at PASSIVE_LEVEL that
    could then take an APC interrupt.
    Neill.
     
    Neill Clift [MSFT], Sep 15, 2003
    #4
  5. Daniel

    Ray Trent Guest

    That's a slightly oversimplified answer. On a multiprocessor machine
    (including single Intel HTT CPUs that act like MPs), a lower IRQL
    interrupt is not masked on the other processor.
     
    Ray Trent, Sep 15, 2003
    #5
  6. The ISR runs under an interrupt spinlock, and I think you can change IRQL
    under which it runs. You won't change IRQL of the IRQ line, though, so it
    won't give the physical interrupt line higher priority.

    So the answer is: you can prevent your ISR from being interrupted, by giving
    it higher IRQL, but you cannot change the interrupt line priority.
     
    Alexander Grigoriev, Sep 16, 2003
    #6
  7. IMHO, but the "interrupt priority" idea is due to stupidity of the 8259
    interrupt controller.

    What is the conceptual need of masking some interrupts off while executing this
    particular interrupt? Why masking this particular interrupt only is not enough?
    It is enough to implement KeSynchronizeExecution.

    Why raising to DIRQL 10 must mask away IRQ 9? Why not allow the device on IRQ 9
    to interrupt the ISR of IRQ 10?

    Maybe APIC allows such a mode, when all interrupts are always unmasked while
    handling this particular interrupt?
    Correct. If there would be a way of governing the IRQL for drivers, then all
    driver writers would make their drivers to use the highest IRQL, so, the
    feature would be useless.

    Usual PCs work fine regardless of the IRQLs Windows gave to hardware. Even IDE
    CD-ROM in PIO mode, which is the most renowned "spender of time in the ISR",
    will coexist with sound card with high latency requirements.
    It extemely depends on motherboard, for instance, it is wrong for systems with
    APIC.
    This must work on non-APIC non-ACPI systems.
     
    Maxim S. Shatskih, Sep 16, 2003
    #7
  8. Daniel

    Pavel A. Guest

    This is because NT adopted the interrupt handling logic from DEC machines, that have (had...) IRQ
    priority independent from IRQ vector. The OS can assign any of four IRQLs to any interrupt source.
    And if you want to sync two ISRs, you just assign same IRQL to their interrupt sources - zero
    software overhead.
    In order to get this flexibility from the stupid 8259 PIC, you need to mask all IRQs whose IRQL is
    less or equal to currently active interrupt. When the ISR returns, the correspondent level is
    unmasked in the either PIC (master or slave).
    If memory serves, in NT4 there was "lazy 8259 masking" optimization: the actual write to 8259 mask
    register did not even occur if interrupts of these levels didn't arrive.
    dunno about APIC: it just works so why bother to rtfm...

    Regards,
    -PA
     
    Pavel A., Sep 17, 2003
    #8
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.