Howdy IngoWolf,
You may want to explore the /3GB switch, see Extending Virtual Memory Usage for 32-bit Windows. This takes virtual address space away from the kernel and allocates it to user mode applications.
Note that fragmentation of virtual memory is still an issue on x86. If you have a buffer that is 128MB, the memory manager has to find a contiguous 128MB hole in the virtual address (VA) space. The memory manager is more likely to succeed if you try to allocate 2x 64MB buffers because it only has to find 2 64MB contiguous holes in the VA. It is easier to simulate this problem if we talk about buffers of say 1 GB. By default, Windows allocates 2GB of virtual address space for applications. However, Microsoft system files reserve 0x70000000-7FFFFFFF (256MB) and MS recommends that 3rd party DLLs reside at virtual address 0x60000000-6FFFFFFF. So, you're left with around 1.5GB of contiguous virtual space for your application (code) and buffers. Any code or data that loads into the middle of this address space would reduce the maximum buffer size that you could allocate. If a tiny DLL loads into the middle of VA, you still have roughly 1.5GB available, but the largest allocation chunk would be about 750 MB, due to the fragmentation.
For example:
Virtual Address Space
0 1.5 1.75 2.0 GB
App DLLs System
{ ~1.5 GB Avail }
Traditional NI-DAQ loads around address 0x21400000 for "legacy" reasons, lets take a look at what happens:
Virtual Address Space
0 1.5 1.75 2.0 GB
App TDAQ DLLs System
{ A } { ~1.0 A}
So, if someone wanted to use large buffers (>1GB) with Traditional NI-DAQ, they would have a challenge. Generally they would move it somewhere else in the virtual address space (hand defragmentation) using the palbase utility.
The 3GB switch makes this:
Virtual Address Space
0 1.5 1.75 2 3GB
App DLLs System
{ ~1.5 GB Avail } {~1GB Avail }
So, with 3GB, you could not allocate a large 2 GB buffer, but you could allocate 2.5 GB of buffers.
I hope that helps.
Jeremiah
NI
