From: Andy Whitcroft <apw@shadowen.org>
To: Christoph Lameter <clameter@sgi.com>
Cc: linux-mm@kvack.org
Subject: Re: virtual mmap basics
Date: Mon, 25 Sep 2006 13:28:25 +0100 [thread overview]
Message-ID: <4517CB69.9030600@shadowen.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0609240959060.18227@schroedinger.engr.sgi.com>
Christoph Lameter wrote:
> Lets say we have memory of MAX_PFN pages.
>
> Then we need a page struct array with MAX_PFN page structs to manage
> that memory called mem_map.
>
> For mmap processing without virtualization (FLATMEM) (simplified)
> we have:
>
> #define pfn_valid(pfn) (pfn < max_pfn)
> #define pfn_to_page(pfn) &mem_map[pfn]
> #define page_to_pfn(page) (page - mem_map))
>
> which is then used to build the commonly used functions:
>
> #define virt_to_page(kaddr) pfn_to_page(kaddr >> PAGE_SHIFT)
> #define page_address(page) (page_to_pfn(page) << PAGE_SHIFT)
>
> Virtual Memmory Map
> -------------------
>
> For a virtual memory map we reserve a virtual memory area
> VMEMMAP_START ... VMEMMAP_START + max_pfn * sizeof(page_struct))
> vmem_map is defined to be a pointer to struct page. It is a constant
> pointing to VMEMMAP_START.
>
> We use page tables to manage the virtual memory map. Page tables
> may be sparse. Pages in the area used for page structs may be missing.
> Software may dynamically add new page table entries to make new
> ranges of pfn's valid. Its like sparse.
>
> The basic functions then become:
>
> #define pfn_valid(pfn) (pfn < max_pfn && valid_page_table_entry(pfn))
> #define pfn_to_page(pfn) &vmem_map[pfn]
> #define page_to_pfn(page) (page - vmem_map))
>
> We only loose (apart from additional TLB use if this memory was not
> already using page tables) on pfn_valid when we have to traverse the page
> table via valid_page_table_entry() if the processor does not have an
> instruction to check that condition. We could avoid the page table
> traversal by having the page fault handler deal with it somehow. But then
> pfn_valid is not that frequent an operation.
pfn_valid is most commonly required on virtual mem_map setups as its
implementation (currently) violates the 'contiguious and present' out to
MAX_ORDER constraint that the buddy expects. So we have additional
frequent checks on pfn_valid in the allocator to check for it when there
are holes within zones (which is virtual memmaps in all but name).
We also need to consider the size of the mem_map. The reason we have a
problem with smaller machines is that virtual space in zone NORMAL is
limited. The mem_map here has to be contigious and spase in KVA, this
is exactly the resource we are short of.
-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>
next prev parent reply other threads:[~2006-09-25 12:28 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 [this message]
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
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=4517CB69.9030600@shadowen.org \
--to=apw@shadowen.org \
--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