Re: 32-bit programs on Windows x64

Wrong
On Thu, 3 Jul 2008 06:17:36 -0700 (PDT), PeteOlcott <PeteOlcott@xxxxxxxxx> wrote:

On Jul 3, 7:52 am, Tim Slattery <Slatter...@xxxxxxx> wrote:
"Peter Olcott" <NoS...@xxxxxxxxxxxxx> wrote:
Can two 32-bit programs each have access to 4.0 GB of RAM,
if there is 8.0 GB of RAM on the system?

On a 32-bit system, each process gets a 4GB virtual memory space. At
any time, bits of this space are in physical RAM, or on disk, or
noplace (since they haven't been allocated yet). The OS keeps track of
where everything is.

If you've got 8GB of RAM, then you must have a 64-bit system. I'm not
sure what the virtual memory space for each process is on a 64-bit
system, but I'm sure it's much larger than the 4GB, 32-bit limit.

Either way, the amount of physical RAM is *not* a limiting factor.
Since with more physical RAM you can have more bits of the VM spaces
in RAM, things will run faster. But things will continue to run even
with small amounts of physical RAM, just more slowly.

--
Tim Slattery
MS MVP(Shell/User)
Slatter...@xxxxxxxxxxx://members.cox.net/slatteryt

64-bit vs. 32-bit architecture
Address space 64-bit Windows 32-bit Windows
Virtual memory 16 terabytes 4 GB
****
8TB user 2GB/3GB user
This is probably based on the erroneous information provided in

http://technet.microsoft.com/en-us/library/bb496995(TechNet.10).aspx

which incorrectly states
"The 64-bit versions of Windows operating systems support up to 16 terabytes of random
access memory (RAM) whereas 32-bit versions can only support up to 4 gigabytes."

This statement is so egregiously wrong that it is mind-boggling. It confuses virtual
address space (VM) with physical address space (RAM) and confuses total address space with
available user address space. 32-bit Windows provides 4GB of virtual address space but in
Win32-based systems, the upper 2GB/1GB is reserved for the operating system and is not
available for user processes. In Win64, the total VM space is 16TB but only 8TB is
available for a user program.

The correct statement would be
"The 64-bit versions of Windows operating systems provide up to 8TB of user virtual memory
whereas 32-bit versions provide only 2GB or 3GB of user virtual memory (depending on boot
configuration)"
*****
Paging file 512 terabytes 16 terabytes
****
But does it matter? The real limit on the paging
file size is the physical disk space available to it,
so to get 16TB of paging space you would need
enough disk space to hold it. This is typically
impractical, so the practical limit of paging space
is usually under 1TB. The theoretical upper limit
is irrelevant, so why worry about it? And have you
really thought of the performance hit if you had
512TB of VM in use on any real machine?
****
Paged pool 128 GB 470 MB
****
not true; the paged pool/nonpaged pool trade off
dynamically, and the non-paged pool
is limited to 80% of the physical address space
Furthermore, pages can move between the paged pool
and the nonpaged pool because you can't do I/O on
pageable pages down in the kernel, so while a page is
a target of an I/O operation, it is temporarily placed
in the nonpaged pool (conceptually)
****
Non-paged pool 128 GB 256 MB
****
not true; the nonpaged pool is everything that is not in
the paged pool, and is limited by physical memory
(nominally 80%). Furthermore, at any given instant,
some number of pages from the paged pool are
temporarily assigned to the nonpaged pool because
they are I/O target pages.
****
System cache 1 terabyte 1 GB
****
what is a system cache? I never heard of it.
There's an L2 cache (hardware), L1 cache (hardware)
and file system cache (software) among other caches.
The file system cache trades off with the paged pool
and cannot exceed it. So you are not going to get
a file system cache that can exceed physical memory.
****

What I am trying to confirm is whether or not 32-bit applications are
limited to being placed in the lowest 4.0 GB of RAM, thus the total
available RAM available to all 32-bit applications could possibly be
constrained to 4.0 GB. Alternatively, each application could have its
virtual address space map to as much as 4.0 GB of actual RAM. I am
guessing that the latter is true.
****
You really need to understand the concept of virtual memory. It is VIRTUAL. It does not
exist except in the imagination of the processor (as established by the page tables and
the Translation Lookaside Buffer, or TLB). I suggest any basic book on operating systems.
There is no restriction about memory placement, even on 32-bit machines; you are
constantly confusing physical and virtual memory, and they are not related. There is no
limitation on the total number of processes no matter what their VM size is. In Win64,
each 32-bit process has a maximum limit of 4GB of virtual memory, and the amount of
physical memory does not even enter the discussion until you start worrying about paging
performance. The total amount of physical RAM is just a random parameter unrelated to
virtual memory. I could run 40 2GB processes on a 512MB machine. Performance would suck,
but I could run them. There is no correlation between virtual addresses and physical
addresses, and in the course of execution, a particular page in VM might appear in
hundreds or thousands of different physical addresses which can be anywhere in the
physical address space (or, to be precise, anywhere in the paged pool, a concept that
itself changes many times per second)

Once you look under the covers, such as in device drivers, life gets a lot more
interesting because the amount of physical RAM available becomes an important parameter in
the design of a device driver, but that's a concern only to device driver writers (e.g.,
you can't lock down (make temporarily part of the non-paged pool) all the pages of a 1GB
user buffer in a 512MB machine, so you have to deal with "mode neither", handle "partial
MDLs" and do your own "MmProbeAndLockPages" and do it only from "passive level" instead of
"dispatch level" which involves using a "system thread" or "dedicated driver thread", and
locked-down memory is physically discontiguous even if virtually contiguous, which leads
to the need to manage "scatter-gather DMA". Absolutely NONE of this is visible at user
level. (I just covered about two hours' of lecture from my driver course in this
paragraph).
joe
****
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Very confused about pagefile!
    ... "Can the Virtual Memory be turned off on a really large machine? ... Doing this would waste a lot of the RAM. ... memory and the paging file are misunderstood. ... remove the virtual memory subsystem, ...
    (microsoft.public.windowsxp.customize)
  • Re: Virtual Memory is too low
    ... Free disk space is valuable if you have insuffient and less or not ... the option windows has provided and provide ... The aspect of virtual memory you refer to as a machine limitation is ... Adding RAM can reduce but not eliminate pagefile ...
    (microsoft.public.windowsxp.general)
  • Re: Virtual Memory is too low
    ... The aspect of virtual memory you refer to as a machine limitation is ... Adding RAM can reduce but not eliminate pagefile usage. ... megabytes of disk space that can be used for regular data is instead ... but is sufficient to run windows, ...
    (microsoft.public.windowsxp.general)
  • Re: virtual memorie
    ... through your downloading activities (often they are bundled together ... As for low virtual memory, virtual memory is hard drive space that ... RAM because the RAM is being used up. ... program it wants a chunk of open space on your hard drive. ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: Memory usage with many w3wp.exe processes
    ... For the moment we are moving forward with using only a single App Pool for ... customers in this configuration and use about 1.3 GB of RAM on each web ... we are using Windows Server 2003 Web Edition ...
    (microsoft.public.dotnet.framework.aspnet)