Virtual memory: Encyclopedia II - Virtual memory - Windows example

Virtual memory - Windows example

Virtual memory has been a feature of Microsoft Windows since Windows 3.1 in 1992. 386SPART.PAR (or WIN386.SWP on Windows 3.11 and Windows for Workgroups) is a hidden file created by Windows 3.x for use as a virtual memory swap file. It is generally found in the root directory, but it may appear elsewhere (typically in the WINDOWS directory). Its size depends on how much virtual memory the system has set up under Control Panel - Enhanced under "Virtual Memory." If a user moves or deletes this file, Windows will BSOD the next time it is started with "The permanent swap file is corrupt" and will ask the user if they want to delete the file (It asks whether or not the file exists). This page file is located at C:\pagefile.sys on all NT-based versions of Windows (including Windows 2000 and Windows XP), though Windows may be configured to place additional pagefiles on other drives.

Windows 95 uses a similar file, except it is named WIN386.SWP, and the controls for it are located under Control Panel - System - Performance tab - Virtual Memory. Windows automatically sets the page file to start 1.5x physical memory, and expand up to 3x physical memory if necessary. If a user runs memory intensive applications on a low physical memory system, it is preferable to manually set these sizes to a value higher than default.

Virtual memory - Misconceptions about the Windows page file

There are some common misconceptions about Windows page file expansion, in that a page file can become heavily "fragmented" and cause "performance issues". The common advice given to avoid this problem is to set a single page file size, and not allow Windows to resize the page file. This is problematic for a few reasons;

• If a Windows application requests more memory than is available from both physical memory and the page file, and Windows cannot resize the page file to fulfill this request, then the memory is not successfully allocated. Many applications (and sometimes Windows itself) will crash (sometimes gracefully, sometimes not) as a result of being unable to allocate more memory.
• Concerns about "performance" are moot when a Windows system is using two or three times its total physical memory. Performance concerns about a further expanding pagefile are not going to be a user's primary concern at this time.
• Concerns about "fragmentation" are not significant, when you consider how and when the page file is used. Windows does not read from or write to the page file in sequential order for long periods of time, so the performance advantages of having a completely sequential page file is minimal at best. Also, if a large number of pages need to be moved in or out of the page file, chances are quite good that other hard-disk activity is taking place at the same time, further reducing performance.

In short, a Windows system does not benefit from having a locked page file size. A larger "minimum" size will indeed help systems with little physical memory by reducing resizing of the page file by the OS. A large "maximum" will incur no performance penalty.

Adapted from the Wikipedia article "Windows example", under the G.N U Free Docmentation License. Please also see http://en.wikipedia.org/wiki