lkml.org 
[lkml]   [1997]   [Jul]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: > 1GB physical on x86: Summary so far
    hmm actually i thought i read somewhere that from i386 on a far 48-bit
    pointer could be used to address more than 4 gigs of memory in a
    segmented model

    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




    \
     
     \ /
      Last update: 2005-03-22 13:39    [W:0.032 / U:32.016 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site