From: Christoph Lameter <clameter@sgi.com>
To: Andy Whitcroft <apw@shadowen.org>
Cc: linux-mm@kvack.org, ak@suse.de
Subject: Re: virtual mmap basics
Date: Mon, 25 Sep 2006 10:11:51 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0609250958370.23475@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0609250922040.23266@schroedinger.engr.sgi.com>
Hmmm... Some more thoughts on virtual memory requirements
A page struct is 8 words on 32 bit platforms = 32 byte
On 64 bit we have 7 words... lets just go with 64.
The memory requirements for a memmap structure covering all of memory
(and also the virtual memory requirements for a virtual memmap)
are
32 bit 4K page size:
Regular:
4GB of adressable memory = 1 mio page structs = 32 MB.
PAE mode:
64GB of memory = 16 mio page structs = 512MB.
Hmm.... So without PAE mode we are fine on i386. The 512MB
virtual space requirement to support all of 64GB of memory with highmem
64G may be difficult to fulfill. This is 1/8th of the address space!
Sparses ability to avoid virtual memory use comes in handy if memory is
actually larger than supported by the processor. But then these
configurations are becoming rarer with the advent of 64 bit processors.
On 64 bit platforms we need 64 byte per potential page.
The maximum on IA64 is 16TB. With a page size of 16k this gets you one 1
Gig of pages which take up 64 GB of address space. This is the
implementation that IA64 used from the beginning.
--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2006-09-25 17:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-24 16:59 Christoph Lameter
2006-09-25 12:28 ` Andy Whitcroft
2006-09-25 16:27 ` Christoph Lameter
2006-09-25 17:11 ` Christoph Lameter [this message]
2006-09-25 21:05 ` Christoph Lameter
2006-09-25 22:22 ` Andy Whitcroft
2006-09-25 23:37 ` Christoph Lameter
2006-09-26 12:06 ` Andy Whitcroft
2006-09-25 18:09 ` Andy Whitcroft
2006-09-25 21:00 ` Christoph Lameter
2006-09-25 23:54 ` virtual memmap sparsity: Dealing with fragmented MAX_ORDER blocks Christoph Lameter
2006-09-26 0:31 ` Christoph Lameter
2006-09-26 12:11 ` Andy Whitcroft
2006-09-26 15:23 ` Christoph Lameter
2006-09-26 8:16 ` Mel Gorman
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=Pine.LNX.4.64.0609250958370.23475@schroedinger.engr.sgi.com \
--to=clameter@sgi.com \
--cc=ak@suse.de \
--cc=apw@shadowen.org \
--cc=linux-mm@kvack.org \
/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