none
NDIS work item scheduling RRS feed

  • Question

  • I'm encountering the following scenario (with Win8 DP) and I'm not sure it's valid:

    1. OS sends OID_DOT11_DELETE_MAC oid to my miniport driver.

    2. The miniport handler queues work item.

    3. Work item begins and finishes execution before oid handler returns. This happens on the same CPU core that handles the oid.

    (Both oid and work item run at PASSIVE_LEVEL).

    Is it possible that the OS performs a context switch from an oid to the work item? Or is it possible that the OS begins WI execution in the context of the oid?

    The DbgView logs looks like this:

    [03] ...some oid handler code (queuing WI among other things)...

    [03] ...WI execution logs...

    [03] ...OID handling continuation logs...

    • Edited by -IgorC- Sunday, July 8, 2012 6:08 PM
    Sunday, July 8, 2012 6:04 PM

Answers

  • Absolutely this can and will happen. The system worker threads run at scheduling priorities that are higher than the default, "normal" priority given to user/kernel threads. Thus, the act of queueing the work item results in a high scheduling priority thread becoming ready to run. In your case, as a result of this the O/S chooses to pre-empt the currently executing thread on the processor with the new, higher priority thread. 

    Interesting to note that this is usually unexpected behavior to the driver writer. In theory, you're trying to defer work to another thread so the requesting thread can go do useful work. However, with the worker threads running at such a high priority they typically run immediately anyway.

    I suppose you could argue that a different processor should have been chosen for the work, but to make that argument you would need to factor in all sorts of details about the other processors and the history of the worker thread.

    -scott


    OSR Online

    • Marked as answer by -IgorC- Tuesday, July 10, 2012 5:19 PM
    Monday, July 9, 2012 7:46 PM

All replies

  • If two threads run in parallel  - especially high-priority ones, like the kernel worker threads - and on two CPUs in parallel - you can see any order of events.  Return STATUS_PENDING, with async completion.

    -- pa

    Sunday, July 8, 2012 9:17 PM
  • If two threads run in parallel  - especially high-priority ones, like the kernel worker threads - and on two CPUs in parallel - you can see any order of events.  Return STATUS_PENDING, with async completion.

    -- pa

    Yes, I'm aware of this. But in my case it occurs on the same CPU ([03] is the CPU id in the above log).
    Monday, July 9, 2012 5:38 AM
  • Absolutely this can and will happen. The system worker threads run at scheduling priorities that are higher than the default, "normal" priority given to user/kernel threads. Thus, the act of queueing the work item results in a high scheduling priority thread becoming ready to run. In your case, as a result of this the O/S chooses to pre-empt the currently executing thread on the processor with the new, higher priority thread. 

    Interesting to note that this is usually unexpected behavior to the driver writer. In theory, you're trying to defer work to another thread so the requesting thread can go do useful work. However, with the worker threads running at such a high priority they typically run immediately anyway.

    I suppose you could argue that a different processor should have been chosen for the work, but to make that argument you would need to factor in all sorts of details about the other processors and the history of the worker thread.

    -scott


    OSR Online

    • Marked as answer by -IgorC- Tuesday, July 10, 2012 5:19 PM
    Monday, July 9, 2012 7:46 PM
  • Thank you, Scott. Just to make sure - if two threads run at PASSIVE_LEVEL, their scheduling priorities might still differ?

    And one more thing - I don't know what scheduling algorithm Windows uses, I suppose it some sort of round robin, is that correct?

    Tuesday, July 10, 2012 5:33 AM
  • Absolutely they can have different scheduling priorities.

    The algorithm is incredibly complicated, you can read about it in the Windows Internals book though. The chapter on scheduling is available for free as a sample from Technet:

    http://technet.microsoft.com/en-us/sysinternals/bb963901.aspx

    -scott


    OSR Online

    Tuesday, July 10, 2012 2:26 PM