Windows NT 5 Internals Preview | ||||||||||||||||||||||||||
Copyright © 1997 Mark Russinovich | ||||||||||||||||||||||||||
Last
Updated December 11, 1997
|
||||||||||||||||||||||||||
Introduction | As I
explore the internals of Windows NT 5.0, this page will be updated with
information on interesting details that aren't covered elsewhere. |
|||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
NT 5 Quantums | Since its release the
NTInternals NTFrob
program has been a popular download favorite. This is because Windows NT
4 Server provides no way to control the quantum (time-slice) lengths of
threads, and Windows NT Workstation provides very little. The size of a
quantum determines how long a thread will be able to execute on a CPU
before the NT scheduler might decide to give a different thread of the
same priority a turn to run. At the end of a quantum the scheduler can
decay the priority of an executing thread if it has been previously
boosted, which might cause it to be switched off the processor and be
replaced with one of a higher priority. Long quantums generally favor
CPU-intensive applications whereas short quantums are better for
environments with many interactive threads of the same priority levels
(see my June and July Windows NT Magazine NT Internals columns on the
scheduler for more information). As one of NT's dynamic tuning measures, quantum lengths hardwired into Workstation and Server assume certain workload characteristics. In Server, all processes have the same quantum length, which is relatively long. This makes Server conducive to environments where there are a small number of applications that are possibly computation-bound. Workstation's quantums are variable and shorter, where lengths can be influenced by whether a process owns the foreground window or not. This arrangement works well for systems where there are several applications running simultaneously, and the applications are interactive in nature. However, many NT users use Workstation or Server in roles that are more typical of the opposite product type, which has lead to a desire for quantum-configurability. Windows NT 5 will include the quantum-knobs NTFrob's appeal has demonstrated users want. NT 4 Quantums Before describing NT 5's quantum settings, let's review what is present in NT 4. As I mentioned, NT 4 Server and Workstation have different quantum lengths. The Server and Workstation O/S image is identical, so the different lengths are taken from an internal quantum-length table that is filled in by NT during its initialization. The values used for Workstation and Server are shown below. The table contain three entries that specify quantum lengths expressed in quantum units. Three quantum units elapse every tick of NT's quantum-tracking timer, and a timer tick period is either 10 milliseconds or 15 milliseconds in length. Uniprocessor x86 systems generally have 10ms periods whereas multiprocessor x86 systems and Alphas have 15ms periods - the HAL is where the period length is defined and thus different vendors and motherboards can have different tick periods.
|
|||||||||||||||||||||||||
Table 1. NT 4 Quantum Tables | ||||||||||||||||||||||||||
What indexes the table is the foreground window priority boost that you configure in the Control Panel System applet under the Performance Tab. The boost slider shown on the dialog (see the screenshot below) has three settings that correspond directly to the index used in the quantum table. Threads belonging to background windows always have a boost index of 0. Foreground threads get their index from the setting in the applet, so their index is 0, 1 or 2 into the table. With the Server quantum table the foreground setting is effectively ignored since the quantum table's entries are all identical, but on Workstation foreground threads can have quantums that are 2 or 3 times longer than background threads. This quantum stretch can enhance the responsiveness of foreground applications. Performing the math with the quantum unit lengths, Workstation threads have quantums that are typically between 10 and 60ms, whereas Server threads have quantums of 120ms. | ||||||||||||||||||||||||||
Figure 1. NT 4 Foreground Boost Slider |
||||||||||||||||||||||||||
So what exactly happens
when you move the slider and hit "Apply"? Two things. The
first is that the applet writes the boost setting to HKLM\System\CurrentControlSet\Control\PriorityControl\Win32PrioritySeperation.
This is so that NT can remember your setting across boots. The second is
that the applet calls the native NT function NtSetSystemInformation
(see my January 1997 Dr.
Dobb's Journal NTRegmon
article for more about the native API). The call communicates the
setting to NT's scheduler, which sets the quantum table index variable
PsPrioritySeparation. The table itself is named PspForegroundQuantum.
When a process is created a variable in its control block is set to the
background quantum length (index 0) retrieved from the table. Whenever a
thread is created or starts a new quantum it obtains its quantum length
from the length stored in the control block of its owning process.
The Win32 kernel-mode component Win32K.sys is responsible for keeping track of which process owns the foreground window, so when this changes it calls the NT Process Manager function PsSetProcessPriorityByClass. PsSetProcessPriorityByClass is called once for the process that is losing the foreground and again for the process that is gaining it, and the function sets the quantum length in the process' control block to the value obtained from the PspForegroundQuantum table - PsPrioritySeparation is used as an index for the process that owns the foreground window. NT 5 Quantums NT 5 keeps the same concept as a quantum table and a foreground window boost, but it has introduced significantly more flexibility, and quantum lengths are no longer tied in any way to whether the system is Workstation or Server. The quantum table is still 3 entries, but there are now 4 different sets of values that the table can contain. Two settings in the NT 5 Performance dialog, seen below, determine which values are used: the quantum type and the quantum length. The quantum type can be fixed or variable. If the quantum type is fixed then foreground window threads always have the same quantum as background threads because the quantum table is initialized with 3 identical values. When the type is variable the values are different so the boost slider has an effect on quantum lengths. The quantum length setting is used to select short or long quantum values. |
||||||||||||||||||||||||||
Figure 2. NT 5 Quantum Controls |
||||||||||||||||||||||||||
The quantum values in the
4 combinations possible with these two controls are shown below. Like in
NT 4, the PsForegroundQuantum is the name of the table. Unlike
NT 4, however, the 4 tables are all present in memory and PsForegroundQuantum
is directed to point at the current one. In NT 5 the NT 4 Workstation
quantums can be achieved with Short-Variable and the NT 4 Server
quantums are achievable with Long-Fixed.
|
||||||||||||||||||||||||||
Table 2. NT 5 Quantum Tables | ||||||||||||||||||||||||||
The NT 5 performance applet causes the quantum settings to be written to the same Registry value for storage as in NT 4 and it invokes NtSetSystemInformation to convey the user's choice to the scheduler. Instead of just specifying a boost, though, it passes the quantum type and length information as well. This quantum control value is encoded as shown below: | ||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
|
||||||||||||||||||||||||||
Here are the definitions
for the bit positions - a bit value of 1 indicates that the choice is in
effect:
Note that with this encoding method
that "undefined" combinations are possible (e.g. having both
the Fixed and Variable bits set or cleared). The scheduler falls back
to its NT 4 logic in such cases (the quantums would be fixed on Server
and variable on Workstation if the F and V bits are identical). |
||||||||||||||||||||||||||