Download Windows_NT_4

Windows NT 4.0 Summary
Based on articles written by Mark Russinovich
Windows NT Architecture Overview
The Windows NT architecture has evolved steadily since NT’s introduction in 1988. The
following diagram illustrates the principal components of the operating system and their relative
places in the system architecture. A description of the key Kernel Mode components follows.
Similar to other operating systems, applications executing in NT’s User Mode have no direct
access to hardware and only restricted access to memory. All components that reside in Kernel
Mode address space have direct access to all hardware and memory.
The services invoked in kernel mode are known as NT’s native API. This API is made up of
about 250 functions that NT’s operating systems access through software-exception system calls.
Software-exception system calls cause a switch from user mode to kernel mode. To carry out
work, system services call on functions in one or more components of NT’s Executive (one or
more of the 250 functions mentioned above) each component in the executive
Hardware Abstraction Layer
This kernel mode layer contains the majority of processor specific code. The Windows NT
developers originally intended ALL hardware specific code to reside in the HAL, however
performance tradeoffs caused some of the code to move into the microkernel.
Microkernel
The Windows NT kernel is a modified microkernel – it falls between a microkernel and
monolithic kernel structure. In NT’s modified microkernel design, operating system
environments execute in User Mode as discrete processes, including DOS, Win16, Win32 OS/2
and POSIX. NT’s User Mode operating system environments implement separate operating
system APIs.
The Windows NT microkernel contains the scheduler and most of the synchronization
primitives. Windows NT offers a broad range of synchronization primitives. Microkernel
architecture gives a system configurability and fault tolerance. Because a subsystem like the
VMM runs as a distinct program in NT’s modified microkernel design, a different
implementation that exports the same interface can replace it.
Executive Subsystems
Above the Hardware Abstraction Layer and the Microkernel are Windows NT’s self-contained
subsystems. Together with the microkernel and the HAL they comprise the kernel mode
components of Windows NT.
Object Manager
The object manager is responsible for resource identification and reference counting. Other
executive subsystems submit requests to the object manager when a particular system resource is
required. The object manager implements the global namespace. All system processes
reference the object manager when a given resource is required.
Security Reference Monitor
Every time a system service requests a resource from the object manager, the object manager
references the Security Monitor to ensure the application (or operating system environment) has
sufficient access to use the resource. The Security Reference Monitor uses Security Identifiers
(SIDs) and Discretionary Access Control Lists (DACLs), and every process in Windows NT has
an access token containing security information.
I/O Manager
All add-on device drivers are connected to Windows NT through the I/O Manager. Interrupt
Service Routines are registered through the I/O Manager and asynchronous, packet-based I/O is
supported.
Configuration Manager
The configuration manager controls the Windows NT system registry, as well as the Windows
Registry API functions.
Process Manager
The project manager executes all native system services including NtCreateProcess and similar
functions. The Process Manager also implements process accounting.
Virtual Memory Manager
The Virtual Memory Manager creates and manages address maps for processes. The Virtual
Memory Manager also does all physical memory allocation. To improve performance, the
VMM implements file memory mapping, memory sharing, and copy-on-write page protection.
File memory mapping involves the automatic load of a file that is identified by the VMM as
being connected to a currently in use portion of a process’ memory map. Memory sharing is
used primarily for communication between processes. Copy-on-write is implemented to
facilitate sharing of one instance of data between many processes.
Cache Manager
Windows NT has a single global file system cache. The cache is file oriented and maintained
entirely by the Cache Manager
Local Procedure Call Facility
This subsystem was created to improve communications performance. Windows NT 4.0 uses
data-copying (port to port) for messages smaller than 256 bytes and shared memory for messages
larger than 256 bytes.
Win32
Windows NT 4.0 has a portion of the Win32 Operating System environment implemented in
kernel mode as an Executive subsystem
Power Manager
This subsystem is integrated into NT 5.0, which Microsoft has announced will be released as
Windows 2000. As NT and Windows95/98 merge, a sophisticated power manager is required
for laptop and palmtop computers. It is likely that Enterprise Servers will not take advantage of
this subsystem.
Plug and Play Manager
This subsystem is also an important feature in Windows 2000 to ensure home computer users are
able to easily add and remove hardware as well as upgrade device drivers for any existing
hardware.
The Windows NT Scheduler
The Windows NT Scheduler is invoked every time a thread’s time quantum expires, a thread
becomes ready to execute (a thread that was waiting for an event, or a new thread is created), and
when a thread begins waiting for an event to occur.
FindReadyThread
Find Ready Thread executes whenever a thread completes its time quantum and the scheduler
must make a decision if another thread will take over the CPU. FindReadyThread also executes
whenever a thread gives up the CPU before its time quantum expires because it begins waiting
for an event.
ReadyThread
A process normally calls ReadyThread whenever a thread is ready to execute. The ReadyThread
algorithm makes a decision as to whether the thread should be scheduled for immediate
execution or placed in the ready queue (Dispatcher Ready queue)
Starvation Prevention
The Balance Set Manager thread wakes up regularly and runs ScanReadyQueues to look for any
threads that have not executed in more than 3 seconds. All such threads are boosted to a priority
of 15 (the highest non-realtime priority)
Boosting and Decay
Threads waiting for an event to occur are given a boost of between 1-6 when the event occurs.
The priority of threads decays every time a thread completes its time quantum. Boosts are
cumulative, so that a thread can make its way to priority 15 (but not higher for non-realtime
threads) and stay around this priority
Processor Affinity in Multi-processor systems
A thread has soft affinity for a particular processor when the processor happens to be the last
processor the thread executed on. Soft Affinity is the primary factor used by the scheduler to
schedule threads for execution. Hard affinity for a processor is a design parameter, and can be
one or more processors that the thread must execute on. An ideal processor can also be
specified for a thread.
When a thread becomes ready to execute, the scheduler will first determine if there are any idle
processors in the thread’s hard affinity list. If there is, then the thread begins executing on that
processor. If not, the scheduler looks to only one other processor: the thread’s soft affinity
processor. If this processor is currently executing a higher priority thread the ready-to-execute
thread is placed in the Dispatcher Ready List (Ready Queue).
Thread Migration
Unnecessary thread migration can result from the scheduler’s soft affinity strategy. In the
example outlined above, if another processor then becomes idle, the ready-to-execute thread may
be scheduled for execution on that processor. The thread has now potentially waited
unnecessarily (it was placed in the Dispatcher Ready List when it was ready to execute even if
there were lower priority threads executing on processor’s other than the thread’s soft affinity
processor) and has also moved to a non-soft affinity processor.
Operating System Environments
NT’s operating system environments are implemented as client/server systems. The operating
system environment is implemented as the server and applications make requests to the server
using the API exported by the client-side libraries linked to the application during compilation.
Applications written for the Win32 OS environment have the are able to make NT native API
calls directly as well as calls to the Win32 server. Win32 provides a higher level interface to the
Windows NT native API, but with often significant performance implications. The performance
hit has supposedly been alleviated largely through the use of messages called Local Procedure
Calls. Many applications that made extensive use of Win32’s drawing functions - the
windowing functions - has very high overhead in earlier implementations of Windows NT.
Windows NT 4.0 removed this problem by moving a portion of Win32 into the Windows NT
Executive. Microsoft has publicly announced that they intend to expand only the Win32 API in
the future and that it is conceivable that the Win32 Operating System server be moved entirely
into the Windows NT Executive
Hard Affinity Optimizations
The Canadian Broadcasting Corporation’s web site is currently hosted on a quad-Pentium II 350
Mhz with 1Gb of common physical memory. The system is running Windows NT 4.0 SP4, IIS
4.0, and MS-SQL 6.5 SP4. A hard affinity optimization has been done with the assistance of
Microsoft to execute SQL threads on three of the four processors and the Active Server Pages
interpreter and Web Server on one of the processors. The web server is continuously waiting for
disk events (although this was alleviated by increasing memory to 1Gb). An 8% performance
improvement was seen through this optimization. That is, the total time to serve one million
page views was reduced by 8% through hard affinity.
Interrupt Handling
Windows NT handles interrupts differently than most other operating systems. In NT, an
interrupt is associated with an Interrupt Service Routine, but that routine does not actually do any
of the data exchange with the device, nor does it contain any system instructions. Rather, the
Interrupt Service Routine contains code necessary to instruct the device to lower its interrupt
signal, and then requests a Deferred Procedure Call (DPC).
DPCs contain the code normally found in an Interrupt Service Routine. The difference is that it
is executed when the processor Interrupt Request Level has been lowered to the Dispatch Level,
which permits general device interrupts to occur. The advantage to this strategy is that the
processor spends much more time at lower Interrupt Request Levels, so that device interrupts can
be serviced more frequently.
The Windows NT scheduler has advanced functionality that looks at a given processors Deferred
Procedure Call queue and makes decisions about which to execute based on status of the
processor’s Dispatcher Ready List. The ISR can assign a priority to a DPC, and the request will
be placed in the DPC queue accordingly.
Symbolic
Name
Purpose
Intel Level
Alpha
Level
High Level
Power Level
IPI Level
Clock Level
Profile Level
Device Level
Dispatch
Level
APC Level
Passive
Level
Highest interrupt level
Power event
Interprocessor signal
Clock tick
Performance monitoring
General device interrupts
Scheduler operations and deferred procedure calls
(DPCs)
Asynchronous procedure calls (APCs)
31
30
29
28
27
3-26
7
7
6
5
3
3-4
2
2
1
1
No interrupts
0
0
One of the biggest problems with NT’s interrupt handling mechanism is that whenever interrupts
are serviced (ISRs and all associated DPCs) the Windows NT Scheduler is inoperative. Note
that Scheduler operations are at Dispatch Level, and the DPCs and ISRs run at Dispatch Level
and Device Level respectively, meaning all interrupts at the Dispatch Level and lower are not
accepted.