Memory sizes of Microsoft Windows Operating Systems
Windows Vista Product Editions
Download 0.82 Mb.
|
- Navigate this page:
- 0.1.1Memory and Address Space Limits
- Memory Support and Windows Operating Systems
- 0.1.1.6 datatype value
- 0.1.2Memory and Address Space Limits
- 0.1.3Physical Memory Limits: Windows Server 2008
- 0.1.4Physical Memory Limits: Windows Vista
- 0.1.5Physical Memory Limits: Windows Home Server
- 0.1.7Physical Memory Limits: Windows XP
- 0.1.8Physical Memory Limits: Windows 2000
Windows Vista Product Editionshttp://www.winsupersite.com/showcase/winvista_editions_final.asp Operating Systems and PAE Support http://www.microsoft.com/whdc/system/platform/server/PAE/pae_os.mspx Memory Limits for Windows Releases http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx Memory Limits for Windows Releases http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx
This topic describes memory limits for supported Windows releases:
Limits on memory and address space vary by platform, operating system, and by whether the IMAGE_FILE_LARGE_ADDRESS_AWARE value of the LOADED_IMAGE structure and 4-gigabyte tuning (4GT) are in use. IMAGE_FILE_LARGE_ADDRESS_AWARE is set or cleared by using the /LARGEADDRESSAWARE linker option. 4-gigabyte tuning (4GT), also known as application memory tuning, or the /3GB switch, is a technology (only applicable to 32 bit systems) that alters the amount of virtual address space available to user mode applications. Enabling this technology reduces the overall size of the system virtual address space and therefore system resource maximums. For more information, see What is 4GT. Limits on physical memory for 32-bit platforms also depend on the Physical Address Extension (PAE), which allows 32-bit Windows systems to use more than 4 GB of physical memory.
PAE: Memory Support and Windows Operating Systemss http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx
Operating systems based on Microsoft Windows NT technologies have always provided applications with a flat 32-bit virtual address space that describes 4 gigabytes (GB) of virtual memory. The address space is usually split so that 2 GB of address space is directly accessible to the application and the other 2 GB is only accessible to the Windows executive software. The 32-bit versions of the Windows 2000 Advanced Server and Windows NT Server 4.0, Enterprise Edition, operating systems were the first versions of Windows to provide applications with a 3-GB flat virtual address space, with the kernel and executive components using only 1 GB. In response to customer requests, Microsoft has expanded the availability of this support to the 32-bit version of Windows XP Professional and all 32-bit versions of Windows Server 2003.
The virtual address space of processes and applications is still limited to 2 GB unless the /3GB switch is used in the Boot.ini file. When the physical RAM in the system exceeds 16 GB and the /3GB switch is used, the operating system will ignore the additional RAM until the /3GB switch is removed. This is because of the increased size of the kernel required to support more Page Table Entries. The assumption is made that the administrator would rather not lose the /3GB functionality silently and automatically; therefore, this requires the administrator to explicitly change this setting. The /3GB switch allocates 3 GB of virtual address space to an application that uses IMAGE_FILE_LARGE_ADDRESS_AWARE in the process header. This switch allows applications to address 1 GB of additional virtual address space above 2 GB. The virtual address space of processes and applications is still limited to 2 GB, unless the /3GB switch is used in the Boot.ini file. The following example shows how to add the /3GB parameter in the Boot.ini file to enable application memory tuning: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(2)\WINNT [operating systems] multi(0)disk(0)rdisk(0)partition(2)\WINNT="????" /3GB
Windows XP Professional Windows Server 2003 Windows Server 2003, Enterprise Edition Windows Server 2003, Datacenter Edition Windows 2000 Advanced Server Windows 2000 Datacenter Server Windows NT Server 4.0, Enterprise Edition Windows NT 4.0 Memory Support. With Microsoft Windows NT 4.0 Workstation and Server operating systems, the maximum amount of physical memory supported is 4 GB. The maximum amount of virtual memory is 2 GB. With Windows NT 4.0 Server, Enterprise Edition, the /3GB switch was first added to Boot.ini. Application Memory Tuning. This capability allows memory-intensive applications to utilize up to 50 percent more virtual memory on Intel-based computers. Application memory tuning provides more of the computer's virtual memory to applications by providing less virtual memory to the operating system. Application Changes. No APIs are required to support application memory tuning. However, it would be ineffective to automatically provide every application with a 3-GB address space. Executables that can use the 3-GB address space are required to have the bit IMAGE_FILE_LARGE_ADDRESS_AWARE set in their image header. If you are the developer of the executable, you can specify a linker flag (/LARGEADDRESSAWARE). To set this bit, you must use Microsoft Visual Studio Version 6.0 or later and the Editbin.exe utility, which has the ability to modify the image header (/LARGEADDRESSAWARE) flag. For more information on setting this flag, see the Microsoft Visual Studio documentation. Some manufacturers preconfigure their applications to use application memory tuning, making it unnecessary for you to make this change. For more information, see your application documentation and contact your application vendor to determine whether they support Large Address Awareness or whether you can enable it in their application. Physical Address Extension. PAE is an Intel-provided memory address extension that enables support of up to 64 GB of physical memory for applications running on most 32-bit (IA-32) Intel Pentium Pro and later platforms. Support for PAE is provided under Windows 2000 and 32-bit versions of Windows XP and Windows Server 2003. 64-bit versions of Windows do not support PAE. PAE allows the most recent IA-32 processors to expand the number of bits that can be used to address physical memory from 32 bits to 36 bits through support in the host operating system for applications using the Address Windowing Extensions (AWE) application programming interface (API). More information about the AWE API can be found at the MSDN Library. KB294418: Comparison of 32-bit and 64-bit memory architecture for 64-bit editions of Windows XP and Windows Server 2003 http://support.microsoft.com/kb/294418 MORE INFORMATION  Virtual memory
This is a method of extending the available physical memory on a computer.
In a virtual memory system, the operating system creates a pagefile, or swapfile, and divides memory into units called pages. Recently referenced pages are located in physical memory, or RAM. If a page of memory is not referenced for a while, it is written to the pagefile. This is called "swapping" or "paging out" memory. If that piece of memory is then later referenced by a program, the operating system reads the memory page back from the pagefile into physical memory, also called "swapping" or "paging in" memory. The total amount of memory that is available to programs is the amount of physical memory in the computer in addition to the size of the pagefile. An important consideration in the short term is that even 32-bit applications will benefit from increased virtual memory address space when they are running in Windows x64 Editions. Applications that are compiled with the /LARGEADDRESSAWARE option, as would be required to take advantage of the /3GB switch in 32-bit Windows, will automatically be able to address 4 GB of virtual memory without any boot time switches or changes to x64 Windows. Plus, of course, the operating system does not have to share that 4 GB of space. Therefore, it is not constrained at all.  Back to the top
Paging file This is a disk file that the computer uses to increase the amount of physical storage for virtual memory.
Back to the top
Hyperspace This is a special region that is used to map the process working set list and to temporarily map other physical pages for such operations as zeroing a page on the free list (when the zero list is empty and the zero page is needed), invalidating page table entries in other page tables (such as when a page is removed from the standby list), and in regards to process creation, setting up the address space of a new process.
Back to the top
Paged pool This is a region of virtual memory in system space that can be paged in and out of the working set of the system process. Paged pool is created during system initialization and is used by Kernel-mode components to allocate system memory. Uniproccessor systems have two paged pools, and multiprocessor systems have four. Having more than one paged pool reduces the frequency of system code blocking on simultaneous calls to pool routines.
Back to the top
Non-paged pool This is a memory pool that consists of ranges of system virtual addresses that are guaranteed to be resident in physical memory at all times and thus can be accessed from any address space without incurring paging input/output (I/O). Non-paged pool is created during system initialization and is used by Kernel-mode components to allocate system memory.
Back to the top
System cache These are pages that are used to map open files in the system cache.
Back to the top
System PTEs A pool of system Page Table Entries (PTEs) that is used to map system pages such as I/O space, Kernel stacks, and memory descriptor lists. 64-bit programs use a 16-terabyte tuning model (8 terabytes User and 8 terabytes Kernel). 32-bit programs still use the 4-GB tuning model (2 GB User and 2 GB Kernel). This means that 32-bit processes that run on 64-bit versions of Windows run in a 4-GB tuning model (2 GB User and 2GB Kernel). 64-bit versions of Windows do not support the use of the /3GB switch in the boot options. Theoretically, a 64-bit pointer could address up to 16 exabytes. 64-bit versions of Windows have currently implemented up to 16 terabytes of address space.
3GB boot.ini option http://msdn.microsoft.com/en-us/library/ms791558.aspx
On 32-bit versions of Windows, the /3GB parameter enables 4 GT RAM Tuning, a feature that enlarges the user-mode virtual address space to 3 GB and restricts the kernel-mode components to the remaining 1 GB. /3GB [ /userva=SizeInMB ] 0.1.1.1Subparameters/userva Specifies an alternate amount of user-mode virtual address space for operating systems booted with the /3GB parameter. SizeInMB Specifies the amount of memory, in megabytes, for user-mode virtual address space. This variable can have any value between 2048 (2 GB) and 3072 (3 GB) megabytes in decimal notation. Windows uses the remaining address space (4 GB minus the specified amount) as its kernel-mode address space. 0.1.1.2CommentsThe /3GB parameter is supported on Windows Server 2003, Windows XP, Windows 2000, and Windows NT. On Windows Vista and later versions of Windows, use the IncreaseUserVA element in BCDEdit. On Windows, by default, the lower 2 GB are reserved for user-mode programs and the upper 2 GB are reserved for kernel-mode programs. You can use this parameter to test the performance of your driver when it is running in a 1 GB kernel. The 4 GT RAM Tuning feature is fully functional on Microsoft Windows NT Server 4.0, Enterprise Edition with Service Pack 3, Microsoft Windows 2000 Advanced Server, Microsoft Windows 2000 Datacenter Server, and all editions of Windows XP, Windows Server 2003, Windows Vista, and later versions of Windows. On other versions of Windows NT and Windows 2000, this feature restricts the kernel to addresses above the 3 GB boundary. However, user-mode applications cannot access more than 2 GB of address space. The /userva subparameter is designed for computers that need more than 2 GB but less than 3 GB of user-mode address space, particularly those that are running memory-intensive user-mode programs. When used without the /3GB parameter, /userva is ignored. The /3GB and /userva parameters are valid only on boot entries for 32-bit versions of Windows on computers with x86 or x64-based processors. To take advantage of the 3 GB available to user-mode programs, the program must be linked with the /LARGEADDRESSAWARE option. On 64-bit versions of Windows Server 2003, the system automatically expands the virtual address space available to 32-bit user-mode programs linked with the /LARGEADDRESSAWARE option as needed without the /3GB boot parameter. On Windows Server 2003 RTM (without Service Pack 1), these 32-bit programs can access up to 3 GB of virtual address space. On Windows Server 2003 with Service Pack 1, they can access up to 4 GB of virtual address space. Native 64-bit user-mode programs can access up to 8 TB of virtual address space. Booting with the /3GB parameter decreases the amount of kernel virtual address space on the system. In order to fit all of the kernel resources within the remaining 1 GB of virtual memory, NT-based Windows operating systems prior to Windows Vista, Windows restricts physical memory to frames below the 16 GB physical boundary and on Windows Vista, it restricts physical memory to frames below the 64 GB boundary. Because allocation of memory resources in Windows Vista is dynamic and, therefore, more adaptable and efficient, the system can devote more memory space to addressing, thereby accommodating more physical memory. The following table lists the physical memory limits of 32-bit Windows operating systems that support the use of more than 4 GB of physical memory with and without the /3GB boot parameter.
On Windows XP, some drivers, especially video adapter drivers with onboard RAM, cannot run with the /3GB parameter because they require more address space than the 1 GB kernel address space permits. 0.1.1.3Examplesmulti(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /fastdetect /3GB multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /fastdetect /3GB /userva=3030 0.1.1.4Bootcfg Commandsbootcfg /raw "/3GB" /A /ID 1 bootcfg /raw "/3GB /userva=3030" /A /ID 2 BCDEdit Vista boot parameters tool http://msdn.microsoft.com/en-us/library/aa906211.aspx
The /set command sets a boot entry option value in the boot configuration data store. Use this command to configure specific boot entry elements, such as kernel debugger settings, data execution protection (DEP) and processor address extension (PAE) options, and to load alternate hardware abstraction layer (HAL) and kernel files. bcdedit /set [{ID}] datatype value
0.1.1.5Parameters[{ID} The {ID} is the GUID that is associated with the boot entry. If you do not specify an {ID}, the command modifies the current operating system boot entry. If a boot entry is specified, the GUID associated with the boot entry must be enclosed in braces { }. To view the GUID identifiers for all of the active boot entries, use the bcdedit /enum command. 0.1.1.6datatype valuebootlog [ yes | no] Enables the system initialization log. hal file Directs the operating system loader to load an alternate HAL file. The specified file must be located in the %SystemRoot%\system32 directory, and its file name must conform to 8.3−character format. increaseuserva Megabytes Specifies the amount of memory, in megabytes, for user-mode virtual address space. This variable can have any value between 2048 (2 GB) and 3072 (3 GB) megabytes in decimal notation. Windows uses the remaining address space (4 GB minus the specified amount) as its kernel-mode address space. kernel file Directs the operating system loader to load an alternate kernel. The specified file must be located in the %SystemRoot%\system32 directory, and its file name must conform to 8.3−character format. loadoptions /busparams=Bus.Device.Function Specifies the target controller when multiple controllers exist. This syntax is appropriate when using either a 1394 cable or a USB 2.0 debug cable for debugging. Bus specifies the bus number, Device specifies the device number, and Function specifies the function number. For USB 2.0 debugging ,the bus parameters must be specified in hexadecimal. For 1394 debugging, the bus parameters must be specified in decimal. nolowmem [ on | off ] Controls the use of low memory. When nolowmem on is specified, this option loads the operating system, device drivers, and all applications into addresses above the 4 GB boundary, and directs Windows to allocate all memory pools at addresses above the 4 GB boundary. nx [Optin |OptOut | AlwaysOn |AlwaysOff] Enables, disables, and configures Data Execution Prevention (DEP), a set of hardware and software technologies designed to prevent harmful code from running in protected memory locations. For information about how to use the Control Panel to change the DEP settings, see the Optin Enables DEP only for operating system components, including the Windows kernel and drivers. Administrators can enable DEP on selected executable files by using the Application Compatibility Toolkit (ACT). Optout Enables DEP for the operating system and all processes, including the Windows kernel and drivers. However, administrators can disable DEP on selected executable files by using System in Control Panel. AlwaysOn Enables DEP for the operating system and all processes, including the Windows kernel and drivers. All attempts to disable DEP are ignored. AlwaysOff Disables DEP. Attempts to enable DEP selectively are ignored. On Windows Vista, this parameter also disables Physical Address Extension (PAE). This parameter does not disable PAE on Windows Server 2008.
Forces only the boot CPU to be used in a computer that has more than one logical processor. For example, the following command configures the current operating system loader to use one processor. bcdedit /set onecpu on pae [ Default | ForceEnable | ForceDisable ] The pae parameter is valid only on boot entries for 32-bit versions of Windows that run on computers with x86-based and x64-based processors. On 32-bit versions of Windows, PAE is disabled by default. However, Windows automatically enables PAE when the computer is configured for hot-add memory devices in memory ranges beyond the 4 GB region, as defined by the Static Resource Affinity Table (SRAT). Hot-add memory supports memory devices that you can add without rebooting or turning off the computer. In this case, because PAE must be enabled when the system starts, it is enabled automatically so that the system can immediately address extended memory that is added between restarts. Hot-add memory is supported only on Windows Server 2008, Enterprise Edition, Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition, and only on computers with an ACPI BIOS, an x86-based processor, and specialized hardware. On a computer that supports hardware-enabled Data Execution Prevention (DEP) and is running a 32-bit version of the Windows operating system that supports DEP, PAE is automatically enabled when DEP is enabled and, on all 32-bit versions of the Windows operating system, except Windows Server 2003 with SP1, PAE is disabled when you disable DEP. To enable PAE when DEP is disabled, you must enable PAE explicitly, by using /set nx AlwaysOff and /set pae ForceEnable. For more information about DEP, see Boot Parameters to Configure DEP and PAE PAE is required to support Cache Coherent Non-Uniform Memory Architecture (known as ccNUMA or NUMA) on computers with x86 processors, although Windows can run in non-NUMA mode on NUMA-capable computers without PAE. Even when it is required, PAE is not enabled automatically. NUMA is supported in all editions of Windows XP and Windows Vista, and in the Enterprise and Datacenter editions of Windows Server 2003. For more information about using the pae parameter and the other parameters that affect PAE configuration, see Boot Parameters to Configure DEP and PAE. If you are running a 32-bit version of Windows Vista on a computer that has 4 GB of memory installed, the amount of RAM available for use could be less than what you would expect. For more information about memory usage, see article Q929605, quietboot [ on | off ] Controls the display of a high-resolution bitmap in place of the Windows boot screen display and animation. In operating systems prior to Windows Vista, the /noguiboot serves a similar function. removememory Megabytes Removes memory from the total available memory that the operating system can use. For example, the following command removes 256 MB of memory from the total available to the operating system associated with the specified boot entry. bcdedit /set {49916baf-0e08-11db-9af4-000bdbd316a0} removememory 256 sos [ on | off ] Controls the display of the names of the drivers as they load during the boot process. Use sos on to display the names. Use sos off to suppress the display. truncatememory address Limits the amount of physical memory available to Windows. When you use this option, Windows ignores all memory at or above the specified physical address. Specify the address in bytes. For example, the following command sets the physical address limit at 1 GB. You can specify the address in decimal (1073741824) or hexadecimal (0x40000000). bcdedit /set {49916baf-0e08-11db-9af4-000bdbd316a0} truncatememory Ox40000000 usefirmwarepcisettings [ yes | no ] Enables or disables the use of BIOS-configured peripheral component interconnect (PCI) resources. vga [ on | off ] Forces the use of the VGA display driver. 0.1.1.7CommentFor more information about specific BCD elements and boot options, you can use the commands BCDEdit /? OSLOADER and BCDEdit /? TYPES OSLOADER. To view the current boot entries and their settings, use the bcdedit /enum command. This command displays the active boot entries and their associated globally unique identifiers (GUID). Use the identifiers with the /set command to configure options for a specific boot entry. For information about commonly used BCDEdit commands, see Memory Limits for Windows Releases http://msdn.microsoft.com/en-us/library/aa366778.aspx
This topic describes memory limits for supported Windows releases:
Limits on memory and address space vary by platform, operating system, and by whether the IMAGE_FILE_LARGE_ADDRESS_AWARE value of the LOADED_IMAGE structure and 4-gigabyte tuning (4GT) are in use. Limits on physical memory for 32-bit platforms also depend on the Physical Address Extension (PAE), which allows 32-bit Windows systems to use more than 4 GB of physical memory. 0.1.2Memory and Address Space LimitsThe following table specifies the limits on memory and address space for supported releases of Windows.
0.1.3Physical Memory Limits: Windows Server 2008The following table specifies the limits on physical memory for Windows Server 2008. Limits greater than 4 GB for 32-bit Windows assume that PAE is enabled.
0.1.4Physical Memory Limits: Windows VistaThe following table specifies the limits on physical memory for Windows Vista.
0.1.5Physical Memory Limits: Windows Home ServerWindows Home Server is available only in a 32-bit edition. The physical memory limit is 4 GB. 0.1.6Physical Memory Limits: Windows Server 2003The following table specifies the limits on physical memory for Windows Server 2003. Limits over 4 GB for 32-bit Windows assume that PAE is enabled.
0.1.7Physical Memory Limits: Windows XPThe following table specifies the limits on physical memory for Windows XP.
0.1.8Physical Memory Limits: Windows 2000The following table specifies the limits on physical memory for Windows 2000.
Operating Systems and PAE Support http://www.microsoft.com/whdc/system/platform/server/PAE/pae_os.mspx
Updated: July 14, 2006 0.1.8.1.1
1.1.1.1.1Related Links
On This Page
Download 0.82 Mb. Share with your friends:
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Change Data Execution Prevention settings page on the Windows Help and How-to Web site. 
