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