From: Andi Kleen <andi@firstfloor.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>,
Martin Steigerwald <ms@teamix.de>,
linux-kernel@vger.kernel.org, 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: Tue, 16 Dec 2008 20:28:26 +0100 [thread overview]
Message-ID: <20081216192826.GZ25779@one.firstfloor.org> (raw)
In-Reply-To: <20081216184742.GL11683@elte.hu>
On Tue, Dec 16, 2008 at 07:47:42PM +0100, Ingo Molnar wrote:
>
> * 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.
Good point.
>
> So in reality MAXMEM should be limited to the max sparsemem-covered
> physical memory range, via the patch below.
I think the SPARSMEM limit problem only happens in the !VMEMMAP case.
It might be better to just disable the config option for !VMEMMAP,
afaik on 64bit NUMA you always want to have VMEMMAP enabled anyways.
That would avoid that particular limit at least and be in general
more efficient.
Like in this patch.
-Andi
---
Always enable vmemmap on x86-64 NUMA
To my knowledge vmemap is the most efficient option on x86-64, so there's no
sense in supporting old style non virtual sparsemem too. On 32bit x86
it still makes some sense due to the limited address space.
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
arch/x86/Kconfig | 1 +
mm/Kconfig | 5 ++++-
2 files changed, 5 insertions(+), 1 deletion(-)
Index: linux-2.6.28-rc4-test/arch/x86/Kconfig
===================================================================
--- linux-2.6.28-rc4-test.orig/arch/x86/Kconfig 2008-11-10 08:50:23.000000000 +0100
+++ linux-2.6.28-rc4-test/arch/x86/Kconfig 2008-12-16 20:12:48.000000000 +0100
@@ -1060,6 +1060,7 @@
depends on X86_64 || NUMA || (EXPERIMENTAL && X86_PC) || X86_GENERICARCH
select SPARSEMEM_STATIC if X86_32
select SPARSEMEM_VMEMMAP_ENABLE if X86_64
+ select SPARSEMEM_VMEMMAP_FORCE if X86_64
config ARCH_SELECT_MEMORY_MODEL
def_bool y
Index: linux-2.6.28-rc4-test/mm/Kconfig
===================================================================
--- linux-2.6.28-rc4-test.orig/mm/Kconfig 2008-10-24 13:35:09.000000000 +0200
+++ linux-2.6.28-rc4-test/mm/Kconfig 2008-12-16 20:13:11.000000000 +0100
@@ -115,8 +115,11 @@
config SPARSEMEM_VMEMMAP_ENABLE
bool
+config SPARSEMEM_VMEMMAP_FORCE
+ bool
+
config SPARSEMEM_VMEMMAP
- bool "Sparse Memory virtual memmap"
+ bool "Sparse Memory virtual memmap" if !SPARSEMEM_VMEMMAP_FORCE
depends on SPARSEMEM && SPARSEMEM_VMEMMAP_ENABLE
default y
help
next prev parent reply other threads:[~2008-12-16 19:16 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 [this message]
2008-12-17 14:30 ` Martin Steigerwald
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=20081216192826.GZ25779@one.firstfloor.org \
--to=andi@firstfloor.org \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=ms@teamix.de \
--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.