linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andy Whitcroft <apw@shadowen.org>
To: Christoph Lameter <clameter@sgi.com>
Cc: linux-mm@kvack.org, ak@suse.de
Subject: Re: virtual mmap basics
Date: Mon, 25 Sep 2006 23:22:16 +0100	[thread overview]
Message-ID: <45185698.5080009@shadowen.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0609251401260.24262@schroedinger.engr.sgi.com>

Christoph Lameter wrote:
> 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.

How does moving to a virtual memmap help here.  The virtual mem_map also
has to be allocated in KVA, any KVA used for it is not available to and
thereby shrinks the size of zone NORMAL?  The size of NORMAL in x86 is
defined by the addressable space in kernel mode (by KVA size), 1GB less
other things we have mapped.  Virtual map would be one of those.

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

As I said the problem is not memory but KVA space.  Zone normal is all
the pages we can map into the kernel address space, its 1Gb less the
kernel itself, less vmap space.  In the current NUMA scheme its then
less the mem_map allocated out of HIGHMEM but mapped into KVA.  In
vmem_map its allocated out of HIGHMEM but mapped into KVA.  The loss is
the same.

-apw

--
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 22:22 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
2006-09-25 22:22         ` Andy Whitcroft [this message]
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=45185698.5080009@shadowen.org \
    --to=apw@shadowen.org \
    --cc=ak@suse.de \
    --cc=clameter@sgi.com \
    --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