From: Martin Steigerwald <ms@teamix.de>
To: linux-kernel@vger.kernel.org
Cc: Ingo Molnar <mingo@elte.hu>, "Rafael J. Wysocki" <rjw@sisk.pl>,
Andi Kleen <andi@firstfloor.org>,
Jeremy Fitzhardinge <jeremy@goop.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: physical memory limit of 64-bit linux
Date: Wed, 17 Dec 2008 15:30:06 +0100 [thread overview]
Message-ID: <200812171530.07946.ms@teamix.de> (raw)
In-Reply-To: <20081216184742.GL11683@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 2103 bytes --]
Am Dienstag, 16. Dezember 2008 schrieb Ingo Molnar:
> * Rafael J. Wysocki <rjw@sisk.pl> wrote:
> > On Tuesday, 16 of December 2008, Martin Steigerwald wrote:
> > > Hi!
> > >
> > > What is the physical memory limit for 64-bit Linux? I read about 40
> > > bit address bus for AMD Athlon X2 (1 TB) and 48 bit for Barcelona X4
> > > (256 TB).
> > >
> > > Is 64-bit linux able to use that amount - provided that one would
> > > manage to build it into a machine? Or does it have a lower limit?
> > >
> > > Looking into the Google crystal ball gives unclear pictures... I tend
> > > to assume that Linux would handle it, but I am not sure.
> >
> > IIRC, the current maximal virtual memory space size of the kernel on
> > x86_64 is 2^46.
>
> Almost: the real current upstream kernel hard memory limit on x86-64 is 44
> bits, i.e. 16 TB.
>
> There's a couple of limits to consider here.
>
> Firstly, there's the architectural limit imposed by the CPU - that is 48
> bits, 256 TB. That is the full virtual memory range that x86-64 CPUs are
> able to address: non-canonical addresses outside that range create an
> exception.
>
> I.e. valid addresses on x86-64 are in the range of:
>
> [ 0xffff800000000000...0x00007fffffffffff ]
>
> Which is minus 128 TB to plus 128 TB.
[...]
> This problem is academic because there are no such systems in existence,
> and because we have another limit on the size of physical memory:
>
> arch/x86/include/asm/sparsemem.h:
> # define MAX_PHYSMEM_BITS 44
So this gives a real 16 TB for userspace applications or is it splitted into
minus 8 TB for kernel and plus 8 TB for userspace again?
How much memory can a process consume? On 32-Bit with 1GB/3GB split its 3
GB... are there special process limits on x86_64 or IA64?
BTW should any of those limits by documented outside of source or this
mailinglist? Maybe doesn't make too much sense cause it could change anytime
anyway.
Ciao,
--
Martin Steigerwald - team(ix) GmbH - http://www.teamix.de
gpg: 19E3 8D42 896F D004 08AC A0CA 1E10 C593 0399 AE90
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
prev parent reply other threads:[~2008-12-17 14:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-12-16 14:56 physical memory limit of 64-bit linux Martin Steigerwald
2008-12-16 15:54 ` Rafael J. Wysocki
2008-12-16 16:44 ` Andi Kleen
2008-12-17 14:12 ` Martin Steigerwald
2008-12-16 18:47 ` Ingo Molnar
2008-12-16 19:07 ` Jeremy Fitzhardinge
2008-12-16 19:23 ` Ingo Molnar
2008-12-16 19:28 ` Andi Kleen
2008-12-17 14:30 ` Martin Steigerwald [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200812171530.07946.ms@teamix.de \
--to=ms@teamix.de \
--cc=andi@firstfloor.org \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rjw@sisk.pl \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.