Section V - How is WinXP different from Windows 2000
So you´ve heard that WinXP is the Windows 2000 kernel loaded down with multimedia stuff and extra eye candy - think so ? Read on ... It´s only 3 pages and you don´t have to fully understand all of it - just notice the enhancements for what they are.
Go Fetch (pre-fetch)
Windows XP utilizes contiguous files strategy, rather than grouping sectors in load order. When Windows XP boots, it requests, or pre-fetches, everything it´ll need for the session at once. In other words it gives a shopping list to the File I/O system, which in turn brings in large chunks of data from multiple files in overlapping requests. Windows XP not only brings in boot and shell code, but device drivers and Registry settings. There are two exceptions but we won´t explain here.
Like the boot-up sequence, when Windows XP runs an application that has been run in prior user sessions, it pre-fetch´s as many of the memory pages it can from the files. With earlier versions of Windows NT/2000, the I/O system would be asked to load pages separately when needed at runtime (designated as demand paging), causing delays while pages were loaded. Windows 2000 did try to optimize by trying to load pages nearby the target pages. Sometimes these extra pages were the ones it needed, often not. However, demand paging did not help when the application needed pages from separate files. Windows XP asks for all pages from all known files (from its knowledge base of previous loads) in one asynchronous request. This lets the I/O subsystem control when to bring in the data. Windows XP monitors the last eight loads of the application and modifies what it "prefetches" as conditions change. It also loads applications with as much overlapping of disk requests as possible. Windows "prefetches" data and Registry settings asynchronously as well as program code. The approach of "prefetching" all code and data in parallel in one request, coupled with on-going monitoring and disk optimization, creates a new self-tuning environment.
I/O Subsystem
The I/O subsystem of the kernel is the workhorse part of the operating system. It provides device drivers with access to system resources, such as memory, plus manages the process. Communications with I/O devices is frequently accomplished using programmed I/O or DMA transfers via different memory buffers and queues. Design decisions in the past did things like allowing device drivers to request memory whether it´s available or not. These are what caused stability problems. The memory architecture of previous Windows also caused performance problems by using more disk-based virtual memory than needed. Improvements have been made in Windows XP that lessen or most often eliminate most of the past stability problems.
Memory Page Pool
No matter how much physical memory your PC has it is always a precious resource. Windows XP has made some improvements to help the situation. In Windows, physical memory has "page pooled" and "non-page pooled" allocations. Non-page pooled memory is for code that is time critical, such as the Virtual Memory Manager (VMM) itself. Page pooled memory is mapped to disk files and allows the OS to swap the memory pages (pagefiles) out to disk if additional physical memory is needed elsewhere.
A memory page represents 4K of physical memory. Memory pages hold system or user data, application or driver code, or Registry data. When an application runs, the executable code is loaded through file mapping objects. The "pre-fetcher" loads these memory pages. Data and settings are also mapped in the same way. The pages in pooled memory are mapped to the file and are referred to as "views" into the file.
Pool memory is managed by a system of descriptors called Page Table Entries (PTE). These incorporate memory page frame numbers, which point to physical memory pages. The memory manager uses various algorithms to determine least used blocks of memory to spool (or page) to the disk when there is a low memory condition, or when a large memory allocation is requested. All Windows virtual memory schemes allow programs to use more memory than is physically available. This can be slow and cause bottlenecks in processing if not handled well. In all previous versions of Windows, memory waste was a prime cause of delays through extra paging to disk.
Enter Windows XP - It increases the maximum memory size that can be mapped by PTEs to approximately 1.3GB. This is about twice Windows 2000´s pool size (this may vary depending on machine or Registry settings). This allows Windows XP to track more memory without reusing PTEs. Windows XP can allocate up to 960MB of contiguous pooled memory if needed on a system with 256MB of RAM. To increase performance, Microsoft has tweaked its algorithms to use less page pool and minimize going to disk.
In earlier versions of Windows, when an application created a file mapping object, the kernel allocated, or "charged" 1/1000th of the file size in PTEs. This was done regardless of the final file view used. For example, if a driver created a 2GB file mapping object, the kernel would charge 2MB of PTEs or memory pages. But if the driver only ends up committing to a small 48K view to the file, the potential for waste is quite obvious. Windows XP does not charge or allocate any PTEs before the view is created, so when the PTEs are needed, they are then created dynamically.
Within the Page Pool, Windows XP now uses the concept of a small and a large pool. When a driver requests PTEs, the memory manager aggressively tries to fulfill the request from the small pool. This saves the large pool for large allocations. It allows the large pool to stay less fragmented thereby giving Windows a better chance of allocating large memory blocks when needed.
Low Memory Improvements
In the battle between drivers and processes for memory the user often loses. Often these conditions are temporary, and are relieved when a driver or process frees up their blocks. When a driver or application process needs memory, it asks the system for a memory allocation. The allocation is either provided or denied. In previous versions of Windows, allocation routines would often designate itself as "must succeed" and was allowed to force the system to give the driver some memory. When memory was low, it would often crash the system. To help get past these occurrences, Windows XP no longer permits drivers to allocate "must-succeed" requests. All internal Windows XP drivers have been rewritten to avoid the use of "must succeed" requests. Third party drivers will also have to comply to earn "digitally signed driver - Microsoft-approved" status. Se why some drivers had to be re-written ?
Windows XP took another step to further memory handling. This is I/O Throttling. To enhance performance Windows tries to do as much processing in parallel as possible. If memory gets to the point where there is none left to allocate, Windows will "throttle down" it´s processing of memory to a page at a time. While this slows the system, it doesn´t crash. In previous version it would often crash.
Under previous versions of Windows, when an application saves keys and settings to the Registry, the kernel puts them into the first space in the Registry that it finds. If there isn´t enough space for all the keys, they are split up. The results are always more fragmentation, and related keys end up on different memory pages. When the application goes to read those keys and settings, the kernel has to read more memory pages from the disk, which causes delays. WinXP has redesigned the Registry code. The algorithm for storing keys and settings has been changed. When an application or the OS goes to store keys and settings, the kernel will search for a space large enough to hold all the data. By better grouping applications all the data is on the same or adjacent memory page. This results in fewer page faults.
Microsoft has also moved the Registry data out of the kernel paged pool memory to mapped files. The Registry management code is still in the kernel but the data is stored outside the kernel memory and it won´t run out as fast. A common practice in programming is to use the presence of a Registry key as a flag in applications. If the key data is present, the application does one thing, if not, it does another. This produces a heavy performance hit when the key does not exist. Some applications create empty trees of keys in the Registry at runtime, and then just leaves them empty. Other applications don´t create keys, but search the Registry for keys. When this happens, the kernel is asked to search the entire Registry or through trees of empty keys. Windows 2000 caches existing Registry keys, but if the key or keys are not found in the cache, a Registry search is performed, and as the registry grows and so do the delays. Windows XP caches both existing and non-existent keys. This results in a relatively large performance boost when an application requests a Registry key. Reason being that it is retrieved from the cache regardless of the key´s existence.
Additional Performance vs Win2K
The best thing you can do to optimize Windows XP is one of the simplest - plainly stated it is to "just to use it". As you launch and exploit applications, Windows observes your behavior and updates a dynamic file called Layout.ini. After every three days, when it senses that the computer is idle, it rearranges the locations of programs on the system hard drive to optimize their launch and execution (keeps file more contiguous, etc.).
XP also speeds up the boot process and optimizes the launch of programs by using "prefetching". Windows observes the code and programs that are used immediately upon boot-up and creates a list of data to "prefetch" very early in the boot process. As individual programs are launched, Windows keeps track of different files and components are accessed. The next time the application is accessed, Windows "prefetches" the necessary items to expedite the application´s launch
Disk optimization and application/boot ´prefetching´ work together in tandem. When XP optimizes file system for faster program access, the data it recorded for the application and boot-up "prefetch" processes is factored in to determine optimal file placement on the disks. OK - "Nuff Said"
