The Memory Manager in Windows Server 2008 has been enhanced to provide better performance, scalability, security, and reliability in the following areas:
- Support for dynamic system address space, including on-demand allocation of system virtual address space and kernel page table pages, and support for very large registries.
- Support for non-uniform memory architecture (NUMA) systems and systems with large pages, including additional device driver and Win32 NUMA API's.
- I/O and section access improvements, including prefetch-style clustering for all types of page faults and system cache read-ahead (essentially pre-loading possibly-needed data into physical memory based on the current operation).
- General performance improvements, including translation buffer optimizations and improvements to internal data structures and algorithmic performance.
Other than the new NUMA-related API's that developers of NUMA-aware applications or drivers need to be aware of, these management changes should be transparent to both applications and drivers.
We've done several posts on the memory address space on 32-bit systems. There is a total of 4GB of virtual address space available (2^32 = 4GB) of which 2GB is allocated to the kernel by default, with the other 2GB being allocated to user-mode memory. Internal components, device drivers, the file system cache, kernel stacks, per-session code data structures as well as paged and nonpaged pool memory are all mapped by the kernel. Prior to Windows Vista and Windows Server 2008, the Memory Manager determined at boot time how much of this address space would be allocated to these different needs. However, this led to situations whereby one area would become depleted, while another area had plenty of free space. Exhaustion of one of these areas led to application and sometimes system failures. To address this, the Dynamic Kernel Address Space feature, in 32-bit versions of Windows Server 2008, the Memory Manager dynamically manages the kernel's address space, allocating and deallocating space to various uses to meet the needs of the system. As a result, the amount of virtual memory being used for paged and nonpaged pool, system PTE's and session space will grow and shrink based on system activity. Thus, the need for manual tuning is reduced given the scaling improvements built into the operating system.
On all versions of Windows prior to Windows Vista, when a physical page (typically 4kb in size) that was owned by a process was reclaimed by the system, the Memory Manager would place the page at the end of the Standby List. If the process wanted to access the page again, the Memory Manager would take the page from the Standby List and reassign it back to the process. If a process wanted access to a new page of physical memory, then the Memory Manager would assign it the page that was at the front of the Standby List. Thus all pages on the Standby List were treated as equals using only the order in which they were placed on the list to sort them. Beginning with Windows Vista, each memory page has a priority ranging from 0 to 7. The Standby List is divided into eight lists that each handle pages of a different priority. When the Memory Manager wants to take a page from the Standby List, it takes pages from the low-priority lists first. A page's priority is usually a reflection of the thread to which it was first allocated. If the page is shared, then it reflects the highest of the memory priorities of the sharing threads. Threads inherit their page-priority value from the process to which they belong. By default, processes have a page-priority value of 5, however there are functions that allow applications and the system to change the process and thread page-priority values. The real benefit to memory priorities comes into play when applications can take aware of the relative priorities of pages. An example of this would be the SuperFetch feature in Windows Vista.
Before we wrap up this post, let's take a look at some Input / Output (I/O) improvements that are included with Windows Server 2008. The three main improvements we will examine are I/O Completion and Cancellation, I/O Prioritization and I/O Request Size. Server applications commonly use a synchronization object called a completion port to wait for the completion of asynchronous I/O requests. Prior to Windows Server 2008, when such an I/O completed, a context switch was made to the thread that issued the I/O and the issuing thread would execute I/O completion work which could possibly interrupt other system activity. The I/O system would then update the completion port status to wake up another thread waiting for the change. In Windows Server 2008, the completion processing is performed by the thread waiting for the completion port. I/O completion is deferred until the completion thread pulls the I/O off the completion port. That way, there are no additional context switches and thread scheduling that could impact an application's (or the system's) performance. In addition, a server can retrieve the results of multiple I/O operations from a completion in one request which avoids transitions to kernel mode.
So what does this look like in practice? One of the most common synchronous operations is the net view command. On earlier versions of Windows, you could not cancel a net view command targeted at a non-existent server. Until the network timeout occurred, the command would not complete. This meant that the application that initiated the command had no way to inform the driver executing the I/O to cancel the request. Windows Vista and Windows Server 2008 provide the ability to cancel most I/O operations, including the open file I/O used by net view and Explorer. Applications have to be updated to respond to user requests to cancel the I/O. The file open and save dialogs that are common to almost every Windows and third-party application now enable the "Cancel" button while trying to display the contents of a folder. In addition, the Ctrl+C shortcut in a command window now allows you cancel synchronous I/O issued via the Net command.
Prior to Windows Vista and Windows Server 2008, system I/O was not prioritized. Without I/O prioritization, background activities such as search indexing, virus scanning and disk defragmenting would impact the responsiveness of foreground operations. So if a foreground task needs disk access, it would have to wait if there was another process performing disk I/O. In Windows Server 2008, there are two new types of disk I/O prioritization that help foreground I/O operations get preference. These two types are priority on individual I/O operations and I/O bandwidth reservations. There is support for the following I/O priorities within the I/O system:
- Critical - used by the Memory Manager
- High - Unused
- Normal - Default Priority
- Low - Default Task Priority
- Very Low - Background Activity
The Memory Manager sets the priority on its I/O requests to Critical in cases where dirty memory data needs to be written to disk under low memory situations to make room in RAM for other data. All background processes - search indexing and disk defragmentation use a Low I/O priority. Third-party applications, such as anti-virus software has to be coded to take advantage of this feature to provide an improved user experience. Applications can take advantage of disk I/O bandwidth reservations to create a reservation that specifies the number of bytes in a period of time (in milliseconds) for each I/O request on a specified file handle. For example, Windows Media Player uses bandwidth reservations to improve the performance for local playback of multimedia files.
Another change to I/O handling is the size of I/O operations. Previously, the Memory Manager and the I/O system limited the amount of data processed by an individual storage I/O request to 64KB. Each I/O request is divided into individual requests that are a maximum of 64KB regardless of the actual size of the I/O request. However, in Windows Server 2008, the I/O request can be as large as 1MB. Since each I/O request requires a transition to kernel-mode to perform transfers on a storage device, the increased size of I/O requests reduces the number of kernel-mode transitions required. This reduces the overhead and improves overall I/O performance. Several Windows applications have been updated to support the larger I/O requests, including the copy functionality within Explorer and the command prompt.
And with that, our first week comes to a close. Tomorrow we will begin looking at Printing in Windows Server 2008. Until next time ...
| Share this post : |
|
|
|
|
|
Microsoft
