NT Dynamic Priority Boost Behavior
Paul F. Bouche'
Priority Boost Behavior as described in various sources:
1) When a thread wait completes its priority is boosted by
some amount (I think I’ve seen 2)
2) Boost occurs on non-Real Time class process threads only
3) Boost never raises dynamic priority above 15
4) NT randomly boosts long waiting low priority threads to
prevent deadlock
5) "for subsytem transactions, while waiting on user calls,
NT sets thread priority to 14"
6) Device transaction completion varying boosts depending on
device class (see NTDDK.h)
Effects of boost:
7) Thread runs at boosted dynamic priority until its quantum ends.
8) At quantum end, dynamic priority decremented unless currently at
base priority
Q1) Is quantum end the only condition which causes priority to decay?
Q2) Is boost added to thread base priority or does it accumulate on
top of current priority?
Q3) Can a devious thread routinely perform some trivial wait prior to
its full
quantum, to maintain its boosted priority despite the best efforts
of the
system to decay it back to baseline?
Q4) Can a non-devious thread performing say network driver I/O (boost =
2)
perform frequent enough operations that its boost keeps it running
generally
higher than its baseline? Consider on NT Server where the quantum
is 120ms,
it would take a thread 240ms before decaying back to baseline.
Q5) Does #5 above imply that WIN32 calls boosts a thread to 14? If so,
do the
normal decay rules apply here?
Q6) Highest-level kernel-mode dispatcher routines run in user context,
but as
kernel threads. I presume these run under the System process. What
is the
base priority of these threads? What is the base priority of the
System
process?
Jamie Hanrahan
Organization: Kernel Mode Systems, San Diego, CA
Mime-Version: 1.0
Newsgroups: microsoft.public.win32.programmer.kernel
On Wed, 11 Mar 1998 19:26:54 -0800, "Paul F. Bouche'"
<pbo...@sequeltech.com> wrote:
>Priority Boost Behavior as described in various sources:
>1) When a thread wait completes its priority is boosted by
> some amount (I think I致e seen 2)
Depends on the reason for the wait.
>[...]
>Q1) Is quantum end the only condition which causes priority to decay?
Yes.
>
>Q2) Is boost added to thread base priority or does it accumulate on
> top of current priority?
No, it's added to the base priority.
>Q3) Can a devious thread routinely perform some trivial wait prior to
>its full
> quantum, to maintain its boosted priority despite the best efforts
>of the
> system to decay it back to baseline?
Sure, but so what? You can also do a SetThreadPriority on yourself to
change the thread's base priority.
>Q4) Can a non-devious thread performing say network driver I/O (boost =
>2)
> perform frequent enough operations that its boost keeps it running
>generally
> higher than its baseline? Consider on NT Server where the quantum
>is 120ms,
> it would take a thread 240ms before decaying back to baseline.
Sure, in fact, that is the intent of the boost, to keep I/O bound
threads at a high priority so they can get into the CPU and get their
NEXT I/O started quickly, to keep the I/O devices busy.
>Q5) Does #5 above imply that WIN32 calls boosts a thread to 14? If so,
>do the
> normal decay rules apply here?
Not all Win32 calls, just User and GDI calls that cause the thread to
wait. GetMessage is a typical example. The normal decay rules do not
apply - the thread gets to run for two quantums at its new priority
and then is decayed back to its previous priority in one step; it does
not do a gradual decay.
>Q6) Highest-level kernel-mode dispatcher routines run in user context,
>but as
> kernel threads. I presume these run under the System process. What
>is the
> base priority of these threads? What is the base priority of the
>System
> process?
I don't know what you mean by "kernel mode dispatcher routines", and
the phrase "in user context, but as kernel threads" is
self-contradictory. If you mean the thread scheduler, no, there is no
thread that runs the scheduler. The scheduler isn't really a separate
entity, it is just a collection of routines that get called by
whomever notices they need to be called. As such it does not have a
priority in the sense that threads have priorities. This has been
thoroughly discussed here and in
comp.os.ms-windows.programmer.nt.kernel-mode before.
The threads in the System process are just there to do things in
kernel mode that do require a unique thread context, such as memory
reclamation from long-idle processes, modified page writing, and so
on. Their base priorities vary from 0 through 23. The concept of
"process base priority" does not apply to the System process as it has
no Win32 context.
--- Jamie Hanrahan, Kernel Mode Systems, San Diego CA (j...@cmkrnl.com)
Drivers, internals, networks, applications, and training for VMS and Windows NT
NT kernel driver FAQ, links, and other information: http://www.cmkrnl.com/
Please reply in news, not via e-mail.
Paul F. Bouche'
Jamie Hanrahan wrote:
>
> >Q6) Highest-level kernel-mode dispatcher routines run in user context,
> > but as kernel threads. I presume these run under the System process.
> > What is the base priority of these threads? What is the base
>
> I don't know what you mean by "kernel mode dispatcher routines", and
> the phrase "in user context, but as kernel threads" is
> self-contradictory. If you mean the thread scheduler, no, there is no
> thread that runs the scheduler. The scheduler isn't really a separate
> entity, it is just a collection of routines that get called by
> whomever notices they need to be called. As such it does not have a
> priority in the sense that threads have priorities. This has been
> thoroughly discussed here and in
> comp.os.ms-windows.programmer.nt.kernel-mode before.
>
> The threads in the System process are just there to do things in
> kernel mode that do require a unique thread context, such as memory
> reclamation from long-idle processes, modified page writing, and so
> on. Their base priorities vary from 0 through 23. The concept of
> "process base priority" does not apply to the System process as it has
> no Win32 context.
>
Sorry about my choice of words. Let me try to re-word my question.
A highest layer device driver's dispatch routines are run in kernel
space
but in the context of the user's thread. I wanted to know at what
priority these threads ran. I thought these threads of execution might
be
run as System process worker threads, but have heard vague descriptions
about each User mode thread having some sort of kernel companion
thread.
In either case, do they "inherit" the current dynamic priority of the
User mode thread which caused them to run, or are they set
independently?
As an aside, do you have any recommendations or guidelines for deciding
when to use a larger dynamic priority boosting versus just creating a
critical IO-bound thread with the "Time Critical" base priority?
There is even the choice of creating a special "RealTime" process for
this single time critical thread!
The documentation is very conservative on these topics, since I am sure
they do not want to see anyone abuse this capability.