Re: Options for growth - Mailing list pgsql-hackers

On Wed, 22 Jan 2003, Sean Chittenden wrote:

> > > By the way, I too wonder which supported OS platform would support
> > > over 4GB of memory on a PC..
> >
> > Linux? I don't think there's any problem handling more than 4G
> > memory in the system. On 32bit architectures, there's of course the
> > 3G (I think) per process limit, but as postgres uses multiprocess
> > and not multithreading, this issue doesn't hit so soon. Of course,
> > if the per process memory is the problem, you'd have to go to 64bit.
>
> Heh, don't kid yourself.  x86 can only handle 4GB of memory
> addressing.  The hack that Linux uses is to swap out 2GB sections of
> RAM to a 4GB+ memory range, then copy the memory range it needs down
> into usable memory space.  Can we say large page tables?  :)
>
> You need an actual 64bit CPU to access more than 4GB of RAM without
> paying for it through the nose.  -sc

No, you do not. If you need to access more than two to three GB
(depending on the OS) of RAM on a 32-bit machine *within a single
process* (as mentioned above), you have a problem. But this problem does
not necessarially involve copying; you could use, e.g., mmap to remap
chunks of your address space.

If you have multiple processes, and your OS is sensibly written, no
memory copying is necessary on the process side. All you do is change
the page tables, and the appropriate physical memory, no matter where in
the physical address space it resides, will be mapped into the 32-bit
virtual memory address space.

That's not to say that there might not be other issues with I/O on, say,
32-bit PCI buses. IIRC, typically PCI bus controllers use physical,
not virtual addresses on the bus for DMA, so you're going to have to
use bounce buffers if you wish a 32-bit PCI card to do I/O outside the
bottom 4 GB of memory. But on the other hand, if you're spending the
money on a motherboard that can take more than 4 GB of RAM, you're
almost certainly getting a few 64-bit PCI slots, and probably you'd also
be spending the money to buy 64-bit PCI disk controllers.

This is not to say you shouldn't go for a 64-bit system, especially
given that the AMD ones are probably going to get awfully cheap fairly
soon. But postgres itself is today not equipment to take any more
advantage of one than it is of a 32-bit system with a greater than
32-bit physical address space. (And there's been doubt about whether
the techniques that would take advantage of this would provide all that
much of a performance improvement, anyway. Still, it seems to me that
it would be pretty cool, when you're doing I/O on a table, just to say,
with one system call, "mmap this entire file containing the table into
my address space," and not have to worry about running out of address
space when you do this on multiple large tables. (And yes, I know this
would actually be, "map this 1 GB chunk of this large table" in the
current postgres implemenation.)

cjs
-- 
Curt Sampson  <cjs@cynic.net>   +81 90 7737 2974   http://www.netbsd.org   Don't you know, in this new Dark Age, we're
alllight.  --XTC