linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Jack Steiner <steiner@sgi.com>
Cc: linux-mm@kvack.org, linux-ia64@vger.kernel.org
Subject: Re: Very large memory configurations:   > 16 TB
Date: Fri, 7 Jan 2011 13:51:35 +0100	[thread overview]
Message-ID: <20110107125135.GD20761@elte.hu> (raw)
In-Reply-To: <20110106170942.GA8253@sgi.com>


* Jack Steiner <steiner@sgi.com> wrote:

> SGI is currently developing an x86_64 system with more than 16TB of memory per 
> SSI. As far as I can tell, this should be supported. The relevant definitions such 
> as MAX_PHYSMEM_BITS appear ok.
> 
> 
> One area of concern is page counts. Exceeding 16TB will also exceed MAX_INT page 
> frames. The kernel (at least in all places I've found) keep pagecounts in longs.
> 
> Have I missed anything? Should this > 16TB work? Are there any kernel problems or 
> problems with user tools that anyone knows of.
> 
> Any help or pointers to potential problem areas would be appreciated...

See this older 2008 mail i wrote about our current x86 64-bit limits:

  http://lkml.indiana.edu/hypermail/linux/kernel/0812.2/00292.html

In that mail i outlined the various limits and the methods that it would take to 
increase those limits, in order of difficulty. It appears we can probably go up to 
32 TB relatively easily and up to 64 TB realistically - 128 TB theoretically.

Note that obviously there can be a number of unknown problems rise up, so you should 
try to simulate a ton of RAM ASAP, before building the hardware ;-) (We could even 
try to add a "memory size debug" feature to the kernel which would inject huge 
'fake' blocks of RAM that the kernel will pretend to have but will skip in the buddy 
allocator or so.

Beyond 64 TB it probably gets painful, very painful - a hardware extension to the 
pagetable and canonical virtual memory space is the pragmatic solution there.

Thanks,

	Ingo

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2011-01-07 12:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-01-06 17:09 Very large memory configurations: > 16 TB Jack Steiner
2011-01-07 12:16 ` Michel Lespinasse
2011-01-07 12:51 ` Ingo Molnar [this message]
2011-01-07 16:31   ` Christoph Lameter
2011-01-07 16:56     ` Ingo Molnar
2011-01-07 17:14       ` Christoph Lameter

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=20110107125135.GD20761@elte.hu \
    --to=mingo@elte.hu \
    --cc=linux-ia64@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=steiner@sgi.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).