linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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 14:05:20 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0609251401260.24262@schroedinger.engr.sgi.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0609250958370.23475@schroedinger.engr.sgi.com>

On Mon, 25 Sep 2006, Christoph Lameter wrote:

> 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 the other hand the PAE sparse approach is not that good for 
i386 with 64GB. Sparse memmmap must be in regular memory and thus we
are forced to use 512 MB of the available 900MB in lowmem for
memmap.

Using a virtual memmap there would allow relocation of the memmap array 
into high memory and would double the available low memory. So may be 
worth even on this 32 bit platform to sacrifice 1/8th of the virtual 
address space for memmap.

So far I am not seeing any convincing case for the current sparsemem table 
lookups. But there must have been some reason that such an implementation 
was chosen. What was it?

--
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>

  reply	other threads:[~2006-09-25 21:05 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
2006-09-25 21:05       ` Christoph Lameter [this message]
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.0609251401260.24262@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