Inside the Windows 2000 Kernel

Microsoft has declared that Windows 2000 (Win2K) is the most important upgrade in the company's history. Microsoft released Windows NT 4.0 in mid-1996, so the company has 3 years of user experience and its own study of the OS to build the Win2K update on. I want to dispel the myth that the Win2K kernel is a rewrite of the NT 4.0 kernel. The Win2K kernel is a tuned and tweaked version of the NT 4.0 kernel, with some significant enhancements in particular areas and a couple of new subsystems. Microsoft intends the Win2K kernel changes to improve the scalability, reliability, and security of the OS over NT 4.0, and to support new features such as Plug and Play (PnP) and power management. In this article, I take you on a quick tour of the kernel changes Microsoft has introduced in Win2K. I won't cover user-mode Win2K components such as Active Directory (AD) or administrative interfaces, which don't rely on kernel changes for their implementation. Space limitations prevent me from describing any particular feature in detail—look for future NT Internals columns to do that.

Scalability Enhancements
NT 4.0 has a reputation for not scaling well on SMP machines, particularly on machines with more than four CPUs. This limitation means that, for enterprise server applications such as database, Web, or email servers, you see diminishing returns on performance as you add CPUs to a system. Benchmarks that this magazine and other industry groups have performed show that the performance drop-off is dramatic when CPUs increase from four to eight. Another aspect of scalability is that applications must perform well with large data sets—large databases, for example. Before the middle and high-end range of enterprise installations will accept any OS, the OS must effectively take advantage of multiprocessors and memory. For this reason, better NT scalability has been a top Microsoft concern for some time. Scalability is a complex equation because it depends not only on an OS's scalability but also on that of the OS's applications. An OS might scale perfectly, but if it doesn't provide appropriate interfaces to its applications, the applications might not be able to scale.

Win2K addresses scalability in several ways. First, Win2K gives to memory-intensive applications the means to use larger amounts of virtual and physical memory than was possible in NT 4.0. How does more memory help an application's scalability? Most server applications must quickly process large amounts of data to perform well. For example, for a database server to scale, the server must handle large databases. Because accessing disks is slow compared with accessing main memory, a server performs best when the data it must access for a database query is located, or cached, in physical memory. NT (and Win2K) is a 32-bit OS that divides its 4GB of virtual memory that is addressable with 32 bits into a lower half, in which NT assigns to applications, and an upper half, where OS and device-driver code and data reside. Thus, NT 4.0 effectively limits an application to managing at most 2GB of data (3GB with the /3GB boot.ini switch on NT Server, Enterprise Edition—NTS/E). A Win2K enhancement, Address Windowing Extensions (AWE—some Microsoft marketing literature refers to AWE as Advanced Windowing Extensions), lets an application manage much more data.

AWE consists of four APIs that applications use to allocate and deallocate physical memory and to obtain references, or windows, in their address space to portions of physical memory. For example, on a system with 4GB of physical memory, a database application might allocate the majority of the memory for its cache. The application then creates windows to the portions of the cache that it must access as it processes database queries. When a query completes, the application closes the windows it created. Figure 1, page 46, shows an example of an application that has allocated physical memory and defined a window to a portion of the physical memory.

Intel recently introduced x86 processors and motherboards that support Physical Address Extension (PAE), a mechanism that lets OSs and applications access more than 4GB of physical memory, even though the processors still use 32-bit virtual addressing. PAE uses 36-bit physical addressing to support up to 64GB of physical memory, so an application using the AWE APIs can create data caches that are close to 16 times as large as the cache sizes possible in NT 4.0. At press time, Microsoft plans to make the AWE APIs available for all versions of Win2K (i.e., Win2K Professional—Win2K Pro, Win2K Advanced Server—Win2K AS, and Win2K Datacenter Server—Datacenter). However, Win2K Pro and Win2K Server will support only as much as 4GB of physical memory. Win2K AS will support as much as 8GB of physical memory, and Datacenter will support as much as 64GB of physical memory.

Other Win2K scalability enhancements address multiprocessor performance. The Job object, a new kernel object, comprises one or more processes that an application or administrator specifies. A Job is a process container with characteristics that Job-object APIs can manipulate. An administrative program can use the APIs to limit the amount of CPU time that the Job can consume before termination, to assign the Job's processes to particular CPUs in an SMP machine, or to control the Job's processes' scheduling priority. Microsoft developed the Job object with batch processing in mind. In batch processing, relatively long-running processes perform certain calculations or data processing. Data mining is one example of a computation that might be well suited to Job objects. A Job object doesn't necessarily enhance the scalability of the computation it encompasses, but the object can enhance the performance of the rest of the system. Because a Job object can assign CPU time, scheduling, working-set sizes, commit limits, and other limitations to the processes the object contains, Job objects can minimize the effect that the computations have on more important or time-critical applications running on a system.

Another scalability enhancement in Win2K changes the length of time that the OS lets threads execute on a CPU before the scheduler might schedule a different thread. Microsoft calls these time lengths quantums, and in NT 4.0 the lengths are shorter on NT Workstation than on NT Server. Shorter quantums are appropriate for systems running multiple interactive applications; longer quantums are best for systems that want to promote the performance of one or two noninteractive applications. On Win2K, systems administrators can configure short or long quantums regardless of whether they run Win2K Pro, Win2K AS, or Datacenter. This flexibility lets administrators decide which lengths are best for the application workloads they run.

Microsoft has also heavily tuned the Win2K kernel for SMP performance. OSs must use spinlocks to ensure that only one CPU at a time accesses key data structures. For example, Win2K uses the scheduler database to keep track of which threads are eligible to execute; if two CPUs modify the database simultaneously, the database could become corrupt. The Win2K kernel uses about 10 locks to protect global data structures such as the scheduler database. The locks that Win2K uses are advanced locks called queued spinlocks. Queued spinlocks have characteristics that make them perform better on SMPs than the standard spinlocks that NT 4.0 uses perform, particularly when you add CPUs to a system.

To increase Win2K's scalability, Microsoft has significantly raised several system components' limits. For example, nonpaged pool (i.e., the maximum amount of available locked kernel memory) doubles in size—from 128MB to 256MB. Paged pool (i.e., pageable kernel memory) also increases—from a maximum of 192MB to almost 470MB. The maximum amount of physical memory that the kernel can map on behalf of device drivers increases from 192MB to approximately 640MB. In addition, the maximum file system cache's virtual size increases from 512MB to almost 1GB. Unfortunately, the Intel chip's virtual address space limit won't let Microsoft apply all those maximum component sizes on one system. However, Win2K's more numerous kernel memory pools let the OS run larger workloads and data sets than NT 4.0 can run, and the Win2K Cache Manager's larger virtual cache improves the Cache Manager's performance in managing cached files.

Finally, Microsoft has tweaked specific kernel subsystems in Win2K. For example, the Memory Manager provides better application performance on SMP machines than it did in NT 4.0.

Security Enhancements
Microsoft has enhanced the NT 4.0 security subsystem for Win2K. The basic security model is unchanged from NT, but some new features make managing security easier for administrators and application programmers. The first new feature is inheritable security. In NT 4.0, an object, such as a file or Registry key, inherits security settings from the container (e.g., a directory or parent key) in which the system creates the object at the time of creation. Subsequent modifications to the container's security settings don't affect the object's settings. This restriction means that you must perform either an administrative or programming manual operation to effect mass updates. Inheritable security lets an administrator or programmer designate specific security settings as inheritable settings; that is, when you apply security settings to a container, all objects within the container adopt the settings.

Another enhancement to Win2K's security subsystem is the addition of object-specific security settings. You apply these settings to AD objects, and a developer can use the settings to precisely control security for property sets and property sheets, which are subsets of AD objects. Globally Unique IDs (GUIDs) identify the subsets, and the object-specific settings specify the GUIDs that apply to the subsets.

The Win2K and NT 4.0 security subsystems use Access Tokens, objects that the subsystems call on to identify users that are logged on to computers. With the Job object comes a new type of Access Token—a Restricted Token. Most tasks that run as Jobs are noninteractive; therefore, running Jobs in restricted security environments where the applications the Jobs run can't perform operations that will adversely affect the rest of the system is desirable. For example, a Job shouldn't be able to reboot a computer or to access certain files or Registry keys. Because a Job must run in the context of a particular user who might be able to reboot a computer or access files or Registry keys, Win2K lets applications designate a Restricted Token, which is a copy of the user's token minus certain privileges.

Microsoft has focused the final Win2K security enhancement on Win2K interoperability with other OSs, such as UNIX or Novell NetWare. The Win2K security model differs substantially from the security models of these other OSs, especially in the way Win2K encodes possible object access types. For example, Win2K has both general access types (e.g., Read, Write) and access types that are specific to particular objects (e.g., List Directory, Create Directory Entry). These differences between OSs prevent Win2K applications from directly manipulating the security of objects that other OSs define. To solve this problem, Win2K introduces provider-independent access rights. A security provider that Microsoft includes in Win2K for interoperability with a particular OS translates provider-independent access rights to the access rights that the other OS understands, letting Win2K applications control security on objects that the other OS creates. So that applications can use provider-independent access rights universally, Win2K supplies a security provider that translates provider-independent access rights to Win2K access rights.

Power Management
Anyone who has used Windows 9x on a laptop knows that power management confers advantages. Power management helps an OS extend a laptop's battery life by reducing the power consumption of devices you don't actively use. Power management also lets you put the entire system into a standby mode; you can later resume working exactly where you left off. Power management requires OS and device-driver support, and with the exception of some drivers that certain laptop vendors specially code, NT 4.0 doesn't have this OS or device-driver support. Win2K introduces power management to NT as part of Microsoft's OnNow initiative.

Win2K implements power management with the Power Manager, a new kernel-mode subsystem. The Power Manager requires the system to have a motherboard and BIOS that implements the Advanced Configuration and Power Interface (ACPI) standard. ACPI defines four device-related power states and six system-related power states, which Figure 2 illustrates, that range from fully on to fully off. The four device-related power states are D0, D1, D2, and D3. D0 always means on and D3 always means off. Individual devices need to decide what states D1 (almost on) and D2 (almost off) mean for them (e.g., if a device doesn't have power modes other than on or off, D1 would mean on, and D2 would mean off).

The Power Manager moves the system power state through various levels according to the power-management setting that an administrator specifies. For example, if you specify that you want your laptop to shut down by saving the contents of memory to disk so that you can restart later where you left off—and you don't want the laptop to consume any battery power in the interim—the Power Manager moves all the laptop's devices to the D3 state, then moves the system power state to the Hibernate level.

Changing devices' power state requires device-driver support. In Win2K, device drivers handle Power Manager requests that query the device's ability to change power level, as well as requests that instruct the device to change state. One power-management requirement in Win2K is that all of a system's device drivers must be responsive to the Power Manager's requests. If just one legacy NT 4.0 device driver is installed, the Power Manager won't change the system power state from the Working mode.

   Previous  [1]  2  Next