Unix Programming - Maximum Physical memory supported

Author

Maximum Physical memory supported

Linny

2007-09-07, 7:24 am

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

Spoon

2007-09-07, 1:32 pm

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

Alex Fraser

2007-09-07, 7:36 pm

"Linny" <linvin333@gmail.com> wrote in message
news:1189163887.751703.266240@y42g2000hsy.googlegroups.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

Gordon Burditt

2007-09-08, 1:43 am

>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).

John Tsiombikas

2007-09-08, 7:31 am

On 2007-09-08, Gordon Burditt <gordonb.bc07z@burditt.org> wrote:
>
>
> 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/

Robert Harris

2007-09-08, 7:31 am

John Tsiombikas wrote:
> On 2007-09-08, Gordon Burditt <gordonb.bc07z@burditt.org> wrote:
>
> 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

John Tsiombikas

2007-09-08, 7:31 am

On 2007-09-08, Robert Harris <robert.f.harris@blueyonder.co.uk> 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.

> 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/

Logan Shaw

2007-09-08, 7:31 am

John Tsiombikas wrote:
> On 2007-09-08, Robert Harris <robert.f.harris@blueyonder.co.uk> wrote:
[vbcol=seagreen]
>
> 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

Robert Harris

2007-09-08, 7:31 am

John Tsiombikas wrote:
> On 2007-09-08, Robert Harris <robert.f.harris@blueyonder.co.uk> wrote:
>
> 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

>
>
> That's irrelevant. I've seen 16bit systems with 20bit addresses (8086),
> 8bit systems with 16bit addresses (Z80) and so on.
>
>
> Ergo, the actual hardware address lines are more than 32, which
> contradicts your first argument

Matthias Buelow

2007-09-08, 7:24 pm

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.

Robert Harris

2007-09-09, 7:33 am

Matthias Buelow wrote:
> Robert Harris 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.
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

Ian Collins

2007-09-09, 7:33 am

Robert Harris wrote:
> Matthias Buelow wrote:
> 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.

Alex Fraser

2007-09-09, 7:33 am

"Robert Harris" <robert.f.harris@blueyonder.co.uk> wrote in message
news:7NNEi.171285$p7.94646@fe2.news.blueyonder.co.uk...
> Matthias Buelow wrote:
[snip][vbcol=seagreen]
> 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

Golden California Girls

2007-09-09, 1:30 pm

Giorgos Keramidas

2007-09-09, 7:35 pm

On Sun, 09 Sep 2007 09:26:34 -0700, Golden California Girls <GldnCAGrls@aol.com.mil> wrote:
>Matthias Buelow wrote:
>
> 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