I plan to run 32-bit Windows XP on a workstation with dual processors, based on Intel's Nehalem microarchitecture, and triple channel RAM. Even though XP is limited to 4 GB of RAM, my understanding is that it will function with more than 4 GB installed, but will only expose 4 GB (or slightly less).
My question is: Assuming that 6 GB of RAM is installed in six 1 GB modules, which physical 4 GB will Windows actually map into its address space?
In particular:
Will it use all six 1 GB modules, taking advantage of all memory channels? (My guess is yes, and that the mapping to individual modules within a group happens in hardware.)
Will it map 2 GB of address space to each of the two NUMA nodes (as each processor has it's own memory interface), or will one processor get fast access to 3 GB of RAM, while the other only has 1 GB?
Thanks!
This question was answered over at SuperUser. Because there are no other responses here, I'm responding to my own question so that the relevant information can easily be found.
Since the question was asked, I have also come across this blog post by Mark Russinovich, explaining how the Windows XP kernel handles memory.
In conclusion, it appears that what happens is that the kernel, even though it is PAE aware, truncates all physical memory addresses to 32-bit, meaning only the lowest physical 4 GB of RAM will be used. This in turn is mapped by hardware to memory modules, and corresponds to the entirety of the first module triplet (3 GB in total), and a third of the second triplet (spread across all three of its modules -- 1 GB in total).
Thus, all memory channels will be exploited, but the amount of memory will not be balanced between NUMA nodes.
Related
Helo, I would like to ask, what does it mean, that processor can access
theoretical 2^32 GB of memory? Does it mean, that there are 2^32 addresses with some instructions in the memory or the instructions itself needs the memory (the data - ones and zeros) ?
And additional question is, how big can by theoretial virtual memory? I always found only recommendations about the virtual memory size, but I would like to know the possible number (theoretical on 32bit machine)
Thank you!
32b CPU can address 2^32 addresses. RAM in your computer has 1 byte per address. So CPU can address 2^32 bytes of data.
As for the virtual memory:
4 Gigs of additional virutal memory, default settings is 2 gigs for system and 2 gigs for process
https://msdn.microsoft.com/en-us/library/windows/desktop/aa366912(v=vs.85).aspx
Please help me understand this :
If my machine has a Ram (Physical memory) of 2 GB , Will I still have a Virtual address space of 4 GB in a 32 bit machine ?
I have read somewhere that a 32 bit application has a max limit of 2 GB virtual address space.
If I have a total of 4 GB VAS , 1 GB is used by OS . So 3 GB is remaining for the applications to use . If I have 2 applications running both using 2 GB of memory ,I want to know if they will work since we are left with only 3GB .Is this where paging comes to picture?
On a 32-bit installation, by default, only 2 GB is made available to processes for their own use. The other 2GB are used by the operating system. On later 32-bit editions of Microsoft Windows it is possible to extend the user-mode virtual address space to 3 GiB while only 1 GiB is left for kernel-mode virtual address space by marking the programs as IMAGE_FILE_LARGE_ADDRESS_AWARE and enabling the /3GB switch in the boot.ini file.
If you wanted to run two applications each with 2GB of memory, you will run into a memory exception when either application tries to use the memory that has already been absorbed but the OS.
I got the clarification here:
http://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/8d63585e-772d-42e5-a40a-72a9500ac0a7/understanding-on-32-bit-environment-application?forum=windowsgeneraldevelopmentissues#8d63585e-772d-42e5-a40a-72a9500ac0a7
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I understand that the memory size that can be accessed by a 32 bit machine is limited to 4GB. Since there are I/O ports like PCIe, USB, Serial, Parallel, PS/2, Audio I/O, CD drive, floppy drive, memory card readers e.t.c that have to be dealt with as well, the result is that less than 4GB RAM is supported by the CPU itself. All the things I have just mentioned and others take quite a bit of memory also.
Now what I am confused about is how can it support several GB of hard disk space? How is it able to access even upto a 1 TB of external storage through these SATA/ATA interfaces. The same goes with the USB mass storage devices like external USB hard disks as well, I am suprised that such a big storage can be accessed by the CPU while being limited to 32 bits. Is there no limit to how big HDD can be supported by a 32 bits processor?
Not sure where to begin :-)
This is a very-very simplistic explanation, not exactly true ever since the 286, but might help you grasp basic concepts:
Memory addressing is done via an address bus: a 32 bit address bus can express 2^32 different addresses. The smallest amount of memory manipulable in one operation is called the "word" size, which is limited by the width of the data bus.
The maximum amount of addressable memory is word size times the number of addresses.
In "block IO" operations, the equivalent of the word size is the block size, usually much bigger. This is a trade-off: larger data can be accessed with the same address length, but flipping a single bit requires overwriting the whole block.
The bigger difference is that the address does not need to be present at the same time on an "address bus" like in memory: commands (and responses) are transmitted in sequential "packets", like on a network. There is thus no hardware-imposed limit on address size, albeit I am sure the protocol specifies a reasonable upper bound.
As you can see, addressable disk size is completely unrelated to CPU bus widths and register sizes.
For most nowadays application developers prefer to deal with 64 bit file pointers. For example lseek64 for linux or SetFilePointer for Windows - so from file point of view you can address 2^64 single file.
But from hardware level it is more interesting - because each disk is splitted (in logical units on clusters, in disk units on sectors). Each cluster is many bytes that can be addressed and read by single query. Operation systems hides from you these operations. But terabyte much more easily to address in terms of cluster.
A 32bit processor can handle much bigger numbers than 32bit (for example using "add with carry" instructions). The processor can write large address values into the address register of the I/O controller (for example using several 32bit data store instructions). Due to this indirect addressing the disk I/O address is independent of the processor bus address.
An excerpt of Wikipedia's article on Physical Address Extension:
x86 processor hardware-architecture is augmented with additional address lines used to select the additional memory, so physical address size increases from 32 bits to 36 bits. This, theoretically, increases maximum physical memory size from 4 GB to 64 GB.
Along with an image explaining the mechanism:
But I can't see how the address space is expanded from 4GB to 64GB. And 4 * 512 * 512 * 4K still equals 4GB, isn't it?
x86 processors running in 32-bit mode uses page translations for memory addresses. This means that there is a mapping layer between the address used by the code (both kernel and user mode) and the actual physical memory. E.g. in Windows all processes map the image of the .exe file to the same address.
The mapping layer between the virtual and physical addresses can normally only map 4GB of memory. With PAE enabled, the 32 bit virtual addresses are mapped 36 bit physical addresses. Still, a single process cannot access more than 4GB at a single time. That's what you see in the image you've pasted, the 32-bit address space of one process. You can also see that the PTE (Page Table Entry) containing the physical address is 64 bit wide.
A PAE aware application can swap in and out different parts of memory into the visible address space to make use of more than 4GB of RAM, but it can only see 4GB at any single point in time.
That's the virtual address space that's still 4GB. The physical address space is larger because the page table entries contain longer physical addresses of pages.
See, the picture says "64-bit PD entry" and "64-bit PT entry". Those extra 32 bits of the entries make up the longer physical addresses of pages.
With this particular scheme your application can still address up to 4GB of memory (minus the kernel portion that's generally inaccessible due to protection) at a time, but if you consider several applications, they can address more than 4GB of memory together.
It does not. The address page never changes. What happens is that via API calls you can SWAP OUT areas of memory against other areas of memory. So, you still have only a full address space of 4gb (2-3 gb usable), but you can have another 2000 blocks of 512mb that you can swap into one part of the address space.
Under Windows Server 2003, Enterprise Edition, SP2 (/3GB switch not enabled)
As I understand it, and I may be wrong, the maximum addressable memory for a process is 4GB.
Is that 2GB of private bytes and 2GB of virtual bytes?
Do you get "out of memory" errors when the private byte limit or virtual byte limit is reached?
It is correct that the maximum address space of a process is 4GB, in a sense. Half of the address space is, for each process, taken up by the operating system. This can be changed with the 3GB switch but it might cause system instability. So, we are left with 2GB of addressable memory for the process to use on its own. Well, not entirely. It turns out that a part of this space is taken up by other stuff such as DLLs an other common code. The actual memory available to you as a programmer is around 1.5GB - 1.7GB.
I'm not sure about how you can handle accidentally going above this limit but I know of games which crash in large multiplayer maps for this reason. Another thing to note is that a 32bit program cannot use more than the 2GB address space on a 64bit system unless they enable the /LARGEADDRESSAWARE:YES linker flag.
Mark Russinovich started a series of posts on this..
Pushing the Limits of Windows: Physical Memory
While 4GB is the licensed limit for 32-bit client SKUs, the effective limit is actually lower and dependent on the system's chipset and connected devices. The reason is that the physical address map includes not only RAM, but device memory as well, and x86 and x64 systems map all device memory below the 4GB address boundary to remain compatible with 32-bit operating systems that don't know how to handle addresses larger than 4GB. If a system has 4GB RAM and devices, like video, audio and network adapters, that implement windows into their device memory that sum to 500MB, 500MB of the 4GB of RAM will reside above the 4GB address boundary.
You can only access 2Gb of memory in total (without the 3Gb switch) on 32bit Windows platforms.
You could run multiple 32bit VMs on a 64bit OS so that each app has access to as much memory as possible if your machine has more than 4Gb.
A lot of people are just starting to hit these barriers, I guess it's easier if your app is in .net or Java as the VMs happily go up to 32Gb of memory on 64bit os.
On 32 bits, if there is enough physical memory and disk space for virtual memory, memory runs out around 3GB since the kernel reserves the address space above 0xC0000000 for itself. On a 64 bits kernel running a 64 bits application, the limit is at 8TB.
For more details, check out MSDN - Memory Limits for Windows Releases
Maximum addressable memory for a 32bit machine is 4GB, for a 64bit machine you can address loads more. (Although some 32bit machines have extension systems for accessing more, but I don't think this is worth bothering with or considering for use).
You get out of memory errors when the virtual limit is reached. On Windows Server 2003, task manager tells you the limit on the performance tab labelled 'Commit Charge Limit'.