JasonB (no@spam.com) on 5/13/07 wrote:
---------------------------
>That's the default, you can tell it to do a 3:1GB split using the /3GB boot switch.
>The developers of the application also need to flag it as being capable of
>using more then 2GB of virtual address space (i.e. they didn't do anything silly
>like assume pointers were equivalent to 32 bit signed integers) by setting the /LARGEADDRESSAWARE
>linker flag. (The flag can actually be set in the executable by anybody using a
>simple tool that comes with Visual C++ but only the developers would know whether it's safe or not.)

>[...]
>I agree 100%, even if you are using 32 bit applications! Under 32 bit XP, our software
>will start having problems allocating more memory once its total footprint exceeds
>1.2-1.5GB (the actual amount varies, I believe due to the degree of virtual addess space fragmentation).
>
>That exact same 32 bit software will happily use well over 2GB of RAM on the same
>PC under XP x64 or 64 bit Vista. I haven't done any testing to confirm this, but
>I also get the feeling that the performance is significantly higher as well -- memory
>allocations start to take a long time when the OS is struggling to cram things into a 2GB virtual address space.
>

Architecturally Windows handles the >1GB situation a little differently than Linux. Notably the assumption that all RAM has to be mapped to kernel space is missing (although that may have changed with the 64-bit versions). So it has plenty of vitual space - the 2GB are statically divided into ranges for different allocations (e.g. kernel pageable - a concept which AFAICT is missing from Linux).

So, special calls to explicitly map user memory to kernel space for access outside of the current process context has always been required.

Off the top of my head, conceptually, I can't really tell why Windows would have trouble with anything up to 2-3GB RAM. It can be a problem with mapping lots of hardware into kernel space, but that is a different issue. (X on Linux doesn't have that problem because it maps it to user space, which is comparatively plentiful)

So it is conceivable that the trouble you app is having with more than 1.5GB RAM under XP may not be so much a HIGHMEM issue, but a matter of XP not being optimized for such amount of RAM. The kernel is pretty old. So, it would be interesting to run the same test with 32-bit Vista.

regards,
Tzvetan