All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.