Re: above 4 GB RAM access for user processes

phil-news-nospam_at_ipal.net
Date: 08/05/04 

Date: 5 Aug 2004 14:57:03 GMT

On Sun, 01 Aug 2004 20:30:18 -0700 Tim Roberts <timr@probo.com> wrote:
| phil-news-nospam@ipal.net wrote:
|
|>On Thu, 29 Jul 2004 21:41:51 -0700 Tim Roberts <timr@probo.com> wrote:
|>
|>| That doesn't necessarily do what the caller was asking. For example, I can
|>| imagine that the Posix shared memory stuff might map in the file 3GB at a
|>| time, with a complete flushing of the old page table entries. There would
|>| have to be specific support for >4GB physical RAMs before it would actually
|>| leave the old data in unmapped pages that are not part of the current
|>| address space, so that they didn't have to be read from disk again.
|>
|>Why is that an issue? If it swapped out, it probably needed to be swapped
|>out. You can't be sure any page anywhere is always resident unless you
|>lock it (inadvisable in the OP's case). But it probably will be if plenty
|>of RAM is present.
|
| Right, but the original caller was asking if a process on 32-bit Linux can
| access more than 4GB physical RAM, as Windows can with AWE. Kasper opined
| that Posix shared memory provided such support, and I was questioning that
| opinion. If the stuff is actually GETTING swapped out, then my process
| isn't really accessing more than 4GB physical RAM.

Regardless of whether you use the mmap trick, or a real 64-bit machine, to
access in excess of 4GB of RAM, whether your pages remain resident in that
greater than 4GB of RAM is a function of how much demand on the system there
is. If you have 16 GB of RAM on a 64-bit machine, and each process is using
8 GB of address space, you cannot say, under your logic, that each process
is accessing RAM if there are several of those processes running, each
causing the others to get swapped out when it needs its next page.

If you want to lock more than 4 GB into one process virtual memory, then in
such a case you really do need a 64-bit machine with more than that much RAM.
But on a 16 GB machine, a single process accessing 8 GB of virtual memory,
whether via 64-bit addresses, or the mmap trick, with nothing else running
on the machine to force otherwise, that virtual memory will be in RAM. The
mmap trick will then be adding the overhead of system calls and page table
juggling. 

-- 
-----------------------------------------------------------------------------
| Phil Howard KA9WGN       | http://linuxhomepage.com/      http://ham.org/ |
| (first name) at ipal.net | http://phil.ipal.org/   http://ka9wgn.ham.org/ |
-----------------------------------------------------------------------------