nick
fb@chibacity.com
Larry M. Augustin wrote:
> Thanks to everyone who responded to my original message. Here's a
> summary and some responses.
>
> Larry
>
> 1. I am talking about physical memory, not virtual memory. Some
> people responded by telling me processes see a 32-bit linear 4GB
> address space. That's true, although the upper 1GB is the kernel.
> But I'm talking about PHYSICAL memory, not the per-process virtual
> address space.
>
> 2. Not everyone seems to believe that there really are x86 systems
> that can support that much memory. Yes, there really are x86 systems
> that can support 4GB of physical memory. The Intel 450GX chipset used
>
> with 4 82451GX MICs allows access to 4GB RAM with 4-way interleaving.
>
> 3. The swap space limit is simply a limit on the number of swap files.
>
> Leonard Zubkoff pointed me to the correct #define:
>
> >From: "Leonard N. Zubkoff" <lnz@dandelion.com>
> >
> > I also seem to be seeing a limit on swap space of 1GB. What about
> > increasing that too?
> >
> >This one is easy. I've been running with 2GB swap possible for quite
> a while.
> >
> > Leonard
> >
> >
> >--- linux/include/linux/swap.h- Mon Jun 3 05:38:37 1996
> >+++ linux/include/linux/swap.h Sun Nov 3 11:04:37 1996
> >@@ -5,7 +5,7 @@
> > #define SWAP_FLAG_PRIO_MASK 0x7fff
> > #define SWAP_FLAG_PRIO_SHIFT 0
> >
> >-#define MAX_SWAPFILES 8
> >+#define MAX_SWAPFILES 16
> >
> > #ifdef __KERNEL__
>
> 4. The physical memory limit is really slightly less than 1GB. It's
> 1GB minus memory used by the kernel. My primitive understanding so
> far is that the kernel maps all physical memory into kernel address
> space, and since the kernel address space is limited to 1GB so it fits
>
> in the upper 1GB of a process' virtual address space, the effective
> limit on physical memory depends on the amount of kernel address space
>
> available for physical memory. This leaves you a few MB short of 1GB.
>
> This has been my experince and seems to be confirmed by Daniel
> Quinlan, Rogier Wolff, and Peter Anvin. However, Ingo Molvar suggests
>
> that 4GB physical should be possible with a minor change to
> PAGE_OFFSET. I don't understand this. Is he suggesting that a
> 2GB/2GB user/kernel address space split as a possible solution, thus
> decreasing the user space virtual memory and providing more address
> space for the kernel to map physical pages?
>
> >From: Daniel Quinlan <quinlan@transmeta.com>
> >
> >Linus told me the (effective?) limit is actually lower than 1GB for
> >possibly different reasons than the ones you mention (allocation of
> >kernel-space memory vs. user-space memory?), maybe 768 MB.
> >
> >Basically, he said that some settings need to be changed, but it
> >sounded like a minor change.
> >
> >--
> >Daniel Quinlan (at work) Linux, our last best hope for Unix
> >quinlan@transmeta.com http://www.pathname.com/~quinlan/
>
> >From: R.E.Wolff@BitWizard.nl (Rogier Wolff)
> >Content-Type: text
> >
> >Larry M. Augustin wrote:
> >>
> >>
> >> We're testing some x86 systems with more than 1GB of RAM. Linux on
>
> >> x86 seems to be limited to 1GB of physical memory. This suprised
> me a
> >> bit since I thought 386 PTE's had 20 bits for physical page
> addresses
> >> (4GB physical). Is there a 1GB physical limit, what's the reason
> for
> >> the limit, and what would need to change to increase this to 4GB?
> >
> >1) Are you sure your chipset supports more than 1G of memory?
> >
> >2) The Linux kernel uses the top 1G of memory as a direct map to
> >physical memory. The rest can be used to access processes' memory (or
>
> >something like that....:-).
>
> >From: hpa@transmeta.com (H. Peter Anvin)
> >
> >Well, the problem is basically that all of memory is direct-mapped in
>
> >the kernel address space slot, which is 1 GB in size. This includes
> >I/O boards, as well. If you outgrow that slot, then you have to
> >change your page tables before you can touch arbitrary memory from
> >kernel space, which is a major lose. It can probably be dealt with,
> >but it is not a trivial obstacle, unfortunately. One can't even get
> >around it by using segment registers, since those still point into
> the
> >32-bit linear address space.
> >
> >P6 machines actually have a 36-bit physical address space, but still
> >only 32-bit linear...
> >
> > -hpa
>
> >From: Ingo Molnar <mingo@pc7537.hil.siemens.at>
> >
> >yes but there should be no problem going as high as 3.9G physical
> memory
> >with the current Linux architecture. None of the user-space tools
> relies
> >on the size/layout of user-space virtual memory. (up to 2.0G physical
>
> >memory is safe when 1 process wants to use up _all_ the memory ...
> should
> >be rare)
> >
> >AFAIR, Sparcs already have a boot-time PAGE_OFFSET variable. For x86
> it
> >shouldnt be much more than to change PAGE_OFFSET, but i havent tried
> it
> >yet, there might be some bugs in x86 specific files. [but from the
> >generic code point of view it's really as simple as to redefine
> >PAGE_OFFSET and recompile the kernel]
> >
> >> P6 machines actually have a 36-bit physical address space, but
> still
> >> only 32-bit linear...
> >
> >this is a solution for more than 4G of physical memory, although
> Linux
> >will have hard times utilizing it. Question is what will be more
> common,
> >4G+ 32 bit boxes, or Klamath boxes ... i'm afraid that it will be the
>
> >first one ...
> >
> >-- mingo