| |
Q: Why is there a limit of about 1.4 GB of addressable memory under NT? Why can I not get the max allowable workspace memory (-m) as described in the ANSYS Installation and Configuration Guide for Windows?
A: First with regard to the NT limitations...
Windows NT (and Win2000) is a 32-bit OS. 32 bits = 4Gb
addressable memory. Of the 4Gb allowed, 2Gb is accessible
in USER mode (USER mode is basically accessible to *normal*
processes) and the other 2Gb is reserved for KERNEL mode
(i.e. the OS itself). This memory space is used for both
the executable code and any memory that the executable
requests. To be technically accurate, this is the 'virtual
address space'. Physical RAM is mapped into the virtual address
space by the OS, and is of no consequence in this discussion,
except to say that the fundamental limit in the situation
at hand is the 'virtual' address space, not the physical one.
Here's a detailed explaination of NT and it's virtual memory
management design.
On Windows NT 4.0/2000 Workstation and Server editions,
this limit is hard coded and cannot be altered. On Windows 2000
Advanced server edition, there is a boot switch (/3Gb)which
changes the allocation limits to 3Gb USer, 1Gb Kernel, as long
as the executable you want to take advantage of this has been
built in a certain way - which we don't currently do.
Here's a summary of the VM limits...
Here's info on the boot switches, including the /3Gb I mentioned...
So now that we are all experts on Virtual Memory on Windows...
The real problem that you are seeing with not being able
to get more than about 1.2Gb is due to something known as
'virtual memory fragmentation', and is not fundamentally a limit
of the NT OS itself. VM fragmentation is similar in concept to
HDD fragmentation. The reason you are seeing this VM fragmentation
has a lot to do with what are called 'Dynamic Link Libraries'
(DLL's), a.k.a. Shared libraries on UNIX.
Along with the main executable (ansys.exe), the Boeing solver,
TCL, etc (which we have build control over) there are a lot of
system DLL's that also get loaded into the process address space.
The OS decides 'where' to load a DLL using a kind of 'best fit'
policy. The problem is that this is also the same address space that
we use for dynamic memory allocation (using the -M switch), and since
we need very large, contiguous blocks, we end up with rather large,
unusable 'gaps' in this virtual address space because no DLL was placed
in it, and it's not large enough for us to use, and so these gaps
essentially become wasted space.
We have been experimenting here at ANSYS with various build options to
alter the default load-time behaviour (to reduce these gaps) and have
managed to improve the situation considerably. I don't know when this
will hit the streets, (I'll leave that up to the product/release managers)
but we have internally been able to get a fairly significant improvement,
up to 1.6Gb that I know of personally.
Until Win64 (or WindowsVLM, 'very large memory' extensions), this 2Gb
(or 3Gb with the boot time switch on Win2000 Advanced Server) limit will
always exist.
Hope this clarifies the situation for everyone.
|