Maximum Physical memory supported - Unix

This is a discussion on Maximum Physical memory supported - Unix ; Hi, What is the maximum physical memory that a 32 bit linux system can support ? I assumed it was 4GB based on the processor's capability to access 32 bit memory addresses but I was surprised when came across information ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: Maximum Physical memory supported

  1. Maximum Physical memory supported

    Hi,
    What is the maximum physical memory that a 32 bit linux system can
    support ?
    I assumed it was 4GB based on the processor's capability to access 32
    bit memory addresses but I was surprised when came across information
    on the net that mentioned 16 GB , 32 GB etc.

    In this regards, can anyone throw light on factors that determine the
    maximum physical memory that a *nix system can support.

    Thanks
    Linny


  2. Re: Maximum Physical memory supported

    Linny wrote:

    > What is the maximum physical memory that a 32 bit linux system can
    > support ?
    > I assumed it was 4GB based on the processor's capability to access 32
    > bit memory addresses but I was surprised when came across information
    > on the net that mentioned 16 GB , 32 GB etc.
    >
    > In this regards, can anyone throw light on factors that determine the
    > maximum physical memory that a *nix system can support.


    Take a look at arch/i386/Kconfig
    http://lxr.linux.no/source/arch/i386/Kconfig

    choice
    prompt "High Memory Support"
    default HIGHMEM4G if !X86_NUMAQ
    default HIGHMEM64G if X86_NUMAQ

    config NOHIGHMEM
    bool "off"
    depends on !X86_NUMAQ
    ---help---
    Linux can use up to 64 Gigabytes of physical memory on x86 systems.
    However, the address space of 32-bit x86 processors is only 4
    Gigabytes large. That means that, if you have a large amount of
    physical memory, not all of it can be "permanently mapped" by the
    kernel. The physical memory that's not permanently mapped is called
    "high memory".

    If you are compiling a kernel which will never run on a machine with
    more than 1 Gigabyte total physical RAM, answer "off" here (default
    choice and suitable for most users). This will result in a "3GB/1GB"
    split: 3GB are mapped so that each process sees a 3GB virtual memory
    space and the remaining part of the 4GB virtual memory space is used
    by the kernel to permanently map as much physical memory as
    possible.

    If the machine has between 1 and 4 Gigabytes physical RAM, then
    answer "4GB" here.

    If more than 4 Gigabytes is used then answer "64GB" here. This
    selection turns Intel PAE (Physical Address Extension) mode on.
    PAE implements 3-level paging on IA32 processors. PAE is fully
    supported by Linux, PAE mode is implemented on all recent Intel
    processors (Pentium Pro and better). NOTE: If you say "64GB" here,
    then the kernel will not boot on CPUs that don't support PAE!

    The actual amount of total physical memory will either be
    auto detected or can be forced by using a kernel command line option
    such as "mem=256M". (Try "man bootparam" or see the documentation of
    your boot loader (lilo or loadlin) about how to pass options to the
    kernel at boot time.)

    If unsure, say "off".

    config HIGHMEM4G
    bool "4GB"
    depends on !X86_NUMAQ
    help
    Select this if you have a 32-bit processor and between 1 and 4
    gigabytes of physical RAM.

    config HIGHMEM64G
    bool "64GB"
    depends on X86_CMPXCHG64
    help
    Select this if you have a 32-bit processor and more than 4
    gigabytes of physical RAM.

    endchoice

    choice
    depends on EXPERIMENTAL
    prompt "Memory split" if EMBEDDED
    default VMSPLIT_3G
    help
    Select the desired split between kernel and user memory.

    If the address range available to the kernel is less than the
    physical memory installed, the remaining memory will be available
    as "high memory". Accessing high memory is a little more costly
    than low memory, as it needs to be mapped into the kernel first.
    Note that increasing the kernel address space limits the range
    available to user programs, making the address space there
    tighter. Selecting anything other than the default 3G/1G split
    will also likely make your kernel incompatible with binary-only
    kernel modules.

    If you are not absolutely sure what you are doing, leave this
    option alone!

    config VMSPLIT_3G
    bool "3G/1G user/kernel split"
    config VMSPLIT_3G_OPT
    depends on !HIGHMEM
    bool "3G/1G user/kernel split (for full 1G low memory)"
    config VMSPLIT_2G
    bool "2G/2G user/kernel split"
    config VMSPLIT_1G
    bool "1G/3G user/kernel split"
    endchoice

  3. Re: Maximum Physical memory supported

    "Linny" wrote in message
    news:1189163887.751703.266240@y42g2000hsy.googlegr oups.com...
    > What is the maximum physical memory that a 32 bit linux system can
    > support ?
    > I assumed it was 4GB based on the processor's capability to access 32
    > bit memory addresses but I was surprised when came across information
    > on the net that mentioned 16 GB , 32 GB etc.
    >
    > In this regards, can anyone throw light on factors that determine the
    > maximum physical memory that a *nix system can support.


    It depends on the machine architecture; in particular, the size of
    *physical* addresses is a fundamental limit. Note that this is completely
    seperate from the size of *virtual* addresses, which are 32 bits on a 32-bit
    Linux system.

    Alex



  4. Re: Maximum Physical memory supported

    >What is the maximum physical memory that a 32 bit linux system can
    >support ?


    The definition of "32 bit system" is a lot fuzzier than you might think.
    "32 bit system" does not necessarily mean "32 bit physical address bus".
    (On x86 systems with PAE, it's 36 bits.)

    >I assumed it was 4GB based on the processor's capability to access 32
    >bit memory addresses but I was surprised when came across information
    >on the net that mentioned 16 GB , 32 GB etc.


    >In this regards, can anyone throw light on factors that determine the
    >maximum physical memory that a *nix system can support.


    The width of the physical address bus is a key limit.
    The code might have lower limits.

    The maximum amount of memory a given process may have is limited by the
    virtual address width, which also may not be 32 bits on a 32 bit system
    (but in the case of x86 in commonly used memory models on such systems,
    it is).


  5. Re: Maximum Physical memory supported

    On 2007-09-08, Gordon Burditt wrote:
    >
    >>What is the maximum physical memory that a 32 bit linux system can
    >>support ?

    >
    > The definition of "32 bit system" is a lot fuzzier than you might think.
    > "32 bit system" does not necessarily mean "32 bit physical address bus".
    > (On x86 systems with PAE, it's 36 bits.)
    >


    It's not at all fuzzy, you're just using the wrong quantity. A the
    number of "bits" that define a system are NOT the address bus bits, but
    rather the data bus bits.
    That's why you can easily have 32bit systems with 36 address bits, 16bit
    systems with 20 address bits (8086), etc.

    --
    John Tsiombikas (Nuclear / Mindlapse)
    nuclear@siggraph.org
    http://nuclear.demoscene.gr/

  6. Re: Maximum Physical memory supported

    John Tsiombikas wrote:
    > On 2007-09-08, Gordon Burditt wrote:
    >>> What is the maximum physical memory that a 32 bit linux system can
    >>> support ?

    >> The definition of "32 bit system" is a lot fuzzier than you might think.
    >> "32 bit system" does not necessarily mean "32 bit physical address bus".
    >> (On x86 systems with PAE, it's 36 bits.)
    >>

    >
    > It's not at all fuzzy, you're just using the wrong quantity. A the
    > number of "bits" that define a system are NOT the address bus bits, but
    > rather the data bus bits.
    > That's why you can easily have 32bit systems with 36 address bits, 16bit
    > systems with 20 address bits (8086), etc.
    >

    No it ain't. Pentiums all have 64 bits on their data bus but that does
    not make them "64 bit systems". What makes a system 32 or 64 bits is the
    number of bits in an instruction address.

    On a 32-bit system the size of a (char *) is 32 bits and on a 64-bit
    system it is 64 bits.

    The hardware and OS may (and in virtual memory systems do) play tricks
    to map 32 bit addresses from different processes to different parts of
    physical memory which may well be either more or less than 32 bits wide.

    Robert

  7. Re: Maximum Physical memory supported

    On 2007-09-08, Robert Harris wrote:
    >
    > John Tsiombikas wrote:
    >> On 2007-09-08, Gordon Burditt wrote:
    >>>> What is the maximum physical memory that a 32 bit linux system can
    >>>> support ?
    >>> The definition of "32 bit system" is a lot fuzzier than you might think.
    >>> "32 bit system" does not necessarily mean "32 bit physical address bus".
    >>> (On x86 systems with PAE, it's 36 bits.)
    >>>

    >>
    >> It's not at all fuzzy, you're just using the wrong quantity. A the
    >> number of "bits" that define a system are NOT the address bus bits, but
    >> rather the data bus bits.
    >> That's why you can easily have 32bit systems with 36 address bits, 16bit
    >> systems with 20 address bits (8086), etc.
    >>

    > No it ain't. Pentiums all have 64 bits on their data bus but that does
    > not make them "64 bit systems". What makes a system 32 or 64 bits is the
    > number of bits in an instruction address.


    Sorry, you are wrong, look it up. Don't feel too bad about it though,
    it's a very common misconception.
    When we talk about n-bit systems that refers to what sort of quantities
    it handles (reads/writes/processes). Addresssing schemes are completely
    irrelevant.

    > On a 32-bit system the size of a (char *) is 32 bits and on a 64-bit
    > system it is 64 bits.


    That's irrelevant. I've seen 16bit systems with 20bit addresses (8086),
    8bit systems with 16bit addresses (Z80) and so on.

    > The hardware and OS may (and in virtual memory systems do) play tricks
    > to map 32 bit addresses from different processes to different parts of
    > physical memory which may well be either more or less than 32 bits wide.


    Ergo, the actual hardware address lines are more than 32, which
    contradicts your first argument

    --
    John Tsiombikas (Nuclear / Mindlapse)
    nuclear@siggraph.org
    http://nuclear.demoscene.gr/

  8. Re: Maximum Physical memory supported

    John Tsiombikas wrote:
    > On 2007-09-08, Robert Harris wrote:
    >> John Tsiombikas wrote:


    >> No it ain't. Pentiums all have 64 bits on their data bus but that does
    >> not make them "64 bit systems". What makes a system 32 or 64 bits is the
    >> number of bits in an instruction address.

    >
    > Sorry, you are wrong, look it up. Don't feel too bad about it though,
    > it's a very common misconception.
    > When we talk about n-bit systems that refers to what sort of quantities
    > it handles (reads/writes/processes). Addresssing schemes are completely
    > irrelevant.


    Then you get into fun things like defining what you mean by "handles".
    For example, the 8086, IIRC, had a 16-bit data bus and 16-bit registers.
    So it's a 16-bit system. But the 8088 had the same sized registers and
    8-bit bus. So is that an 8-bit system or a 16-bit one? Similarly, the
    68000 had 32-bit registers and 16-bit data bus. And the 68008 had 32-bit
    registers but an 8-bit data bus.

    - Logan



  9. Re: Maximum Physical memory supported

    John Tsiombikas wrote:
    > On 2007-09-08, Robert Harris wrote:
    >> John Tsiombikas wrote:
    >>> On 2007-09-08, Gordon Burditt wrote:
    >>>>> What is the maximum physical memory that a 32 bit linux system can
    >>>>> support ?
    >>>> The definition of "32 bit system" is a lot fuzzier than you might think.
    >>>> "32 bit system" does not necessarily mean "32 bit physical address bus".
    >>>> (On x86 systems with PAE, it's 36 bits.)
    >>>>
    >>> It's not at all fuzzy, you're just using the wrong quantity. A the
    >>> number of "bits" that define a system are NOT the address bus bits, but
    >>> rather the data bus bits.
    >>> That's why you can easily have 32bit systems with 36 address bits, 16bit
    >>> systems with 20 address bits (8086), etc.
    >>>

    >> No it ain't. Pentiums all have 64 bits on their data bus but that does
    >> not make them "64 bit systems". What makes a system 32 or 64 bits is the
    >> number of bits in an instruction address.

    >
    > Sorry, you are wrong, look it up. Don't feel too bad about it though,
    > it's a very common misconception.
    > When we talk about n-bit systems that refers to what sort of quantities
    > it handles (reads/writes/processes). Addresssing schemes are completely
    > irrelevant.


    Ah! Well, I suppose that depends on who you are. To a programmer (and
    this is the comp.unix.programmer news group) it does mean the number of
    bits in virtual addresses while the width of the physical data bus and,
    for that matter, the physical address bus, is irrelevant. But to a
    hardware engineer laying out a circuit board, it may well mean something
    completely different.

    But I'm equally sure that the programming view now predominates which is
    why, for example, AMD64 and SPARC64 CPUs are considered 64-bit.

    Robert

    >
    >> On a 32-bit system the size of a (char *) is 32 bits and on a 64-bit
    >> system it is 64 bits.

    >
    > That's irrelevant. I've seen 16bit systems with 20bit addresses (8086),
    > 8bit systems with 16bit addresses (Z80) and so on.
    >
    >> The hardware and OS may (and in virtual memory systems do) play tricks
    >> to map 32 bit addresses from different processes to different parts of
    >> physical memory which may well be either more or less than 32 bits wide.

    >
    > Ergo, the actual hardware address lines are more than 32, which
    > contradicts your first argument
    >


  10. Re: Maximum Physical memory supported

    Robert Harris wrote:

    > No it ain't. Pentiums all have 64 bits on their data bus but that does
    > not make them "64 bit systems". What makes a system 32 or 64 bits is the
    > number of bits in an instruction address.


    That would make the C=64 (6510) a 16-bit machine, the 8086 a 20-bit
    machine and the 80286 a 24-bit machine, which isn't what they were
    specified as, not even by marketing.
    The terminology is a bit fuzzy but I think the one that is accepted most
    widely is that a machine is n-bit if its arithmetic CPU register(s) are
    n bits wide.

  11. Re: Maximum Physical memory supported

    Matthias Buelow wrote:
    > Robert Harris wrote:
    >
    >> No it ain't. Pentiums all have 64 bits on their data bus but that does
    >> not make them "64 bit systems". What makes a system 32 or 64 bits is the
    >> number of bits in an instruction address.

    >
    > That would make the C=64 (6510) a 16-bit machine, the 8086 a 20-bit
    > machine and the 80286 a 24-bit machine, which isn't what they were
    > specified as, not even by marketing.
    > The terminology is a bit fuzzy but I think the one that is accepted most
    > widely is that a machine is n-bit if its arithmetic CPU register(s) are
    > n bits wide.

    Well, times have changed. Good old traditional 8-bit micros like 8080
    and 6800 had 8-bit data buses and 16-bit address buses. Enhanced ones
    like 6809 and Z80 could do 16-bit register arithmetic although we still
    called them 8-bit.
    But nowadays when we talk about 64-bit CPUs, we are really talking about
    addressability: 32-bit Pentiums still have a 64 bit data bus but
    processes can only address a virtual space of 4Gbytes without tricks.
    There are 32 bits of address in their general program counter and data
    pointer registers. And 64-bit Pentiums have 64 bits of address in theirs
    so they can address 2**64 bytes. So it's the size of a (char *) that
    counts in that respect.

    Robert

  12. Re: Maximum Physical memory supported

    Robert Harris wrote:
    > Matthias Buelow wrote:
    >> Robert Harris wrote:
    >>
    >>> No it ain't. Pentiums all have 64 bits on their data bus but that does
    >>> not make them "64 bit systems". What makes a system 32 or 64 bits is the
    >>> number of bits in an instruction address.

    >> That would make the C=64 (6510) a 16-bit machine, the 8086 a 20-bit
    >> machine and the 80286 a 24-bit machine, which isn't what they were
    >> specified as, not even by marketing.
    >> The terminology is a bit fuzzy but I think the one that is accepted most
    >> widely is that a machine is n-bit if its arithmetic CPU register(s) are
    >> n bits wide.

    > Well, times have changed. Good old traditional 8-bit micros like 8080
    > and 6800 had 8-bit data buses and 16-bit address buses. Enhanced ones
    > like 6809 and Z80 could do 16-bit register arithmetic although we still
    > called them 8-bit.
    > But nowadays when we talk about 64-bit CPUs, we are really talking about
    > addressability: 32-bit Pentiums still have a 64 bit data bus but
    > processes can only address a virtual space of 4Gbytes without tricks.


    But the wide data bus is just there to increase memory bandwidth, the
    ALU is still 32 bit.

    --
    Ian Collins.

  13. Re: Maximum Physical memory supported

    "Robert Harris" wrote in message
    news:7NNEi.171285$p7.94646@fe2.news.blueyonder.co. uk...
    > Matthias Buelow wrote:
    >> The terminology is a bit fuzzy but I think the one that is accepted most
    >> widely is that a machine is n-bit if its arithmetic CPU register(s) are
    >> n bits wide.

    [snip]
    > But nowadays when we talk about 64-bit CPUs, we are really talking about
    > addressability: [...]


    I think Matthias Buelow is talking about the "bitness" of a CPU, while you
    are talking about the "bitness" of a system (of which the CPU is just one
    component).

    Alex



  14. Re: Maximum Physical memory supported

    Matthias Buelow wrote:
    > Robert Harris wrote:
    >
    >> No it ain't. Pentiums all have 64 bits on their data bus but that does
    >> not make them "64 bit systems". What makes a system 32 or 64 bits is the
    >> number of bits in an instruction address.

    >
    > That would make the C=64 (6510) a 16-bit machine, the 8086 a 20-bit
    > machine and the 80286 a 24-bit machine, which isn't what they were
    > specified as, not even by marketing.
    > The terminology is a bit fuzzy but I think the one that is accepted most
    > widely is that a machine is n-bit if its arithmetic CPU register(s) are
    > n bits wide.



    Isn't the bit-ness of a processor the maximum number of bits that it
    fetches/writes in a single clock cycle from the data bus?




  15. Re: Maximum Physical memory supported

    On Sun, 09 Sep 2007 09:26:34 -0700, Golden California Girls wrote:
    >Matthias Buelow wrote:
    >> That would make the C=64 (6510) a 16-bit machine, the 8086 a 20-bit
    >> machine and the 80286 a 24-bit machine, which isn't what they were
    >> specified as, not even by marketing.
    >>
    >> The terminology is a bit fuzzy but I think the one that is accepted
    >> most widely is that a machine is n-bit if its arithmetic CPU
    >> register(s) are n bits wide.

    >
    > Isn't the bit-ness of a processor the maximum number of bits that it
    > fetches/writes in a single clock cycle from the data bus?


    Not really. The processor may be able to fetch multiple numbers of
    "words" in a single clock cycle, i.e. because it internally supports
    fetching subsequent bytes in "batch mode". The best description I've
    read so far is the one by matthias Buelow above, and he is very right
    that "the terminology is a bit fuzzy".

    - Giorgos


+ Reply to Thread