From: "Bob Picco" <bob.picco@hp.com>
To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Christoph Lameter <clameter@engr.sgi.com>,
Andy <apw@shadowen.org>, Andrew Morton <akpm@osdl.org>
Subject: Re: [RFC] [PATCH] virtual memmap on sparsemem v3 [0/4] introduction
Date: Sun, 10 Dec 2006 14:47:30 -0500 [thread overview]
Message-ID: <20061210194730.GA10629@localhost> (raw)
In-Reply-To: <20061208155608.14dcd2e5.kamezawa.hiroyu@jp.fujitsu.com>
Hiroyuki KAMEZAWA wrote: [Fri Dec 08 2006, 01:56:08AM EST]
Hi Kame,
> Hi, virtual mem_map on sparsemem/generic patch version 3.
>
> I myself likes this patch.
> But someone may feels this patch is intrusive and scattered.
> please pointing out.
>
> Changes v2 -> v3
> - make map/unmap function for general purpose. (for my purpose ;)
> - drop memory hotplug support. will be posted after this goes in.
> - change pfn_to_page()/page_to_pfn() defintions.
> - add CONFIT_SPARSEMEM_VMEMMAP_STATIC config.
> - several clean ups.
> - drop optimized pfn_valid() patch will be posted later after this goes in.
> - add #error to check vmem_map alignment.
>
> Changes v1 -> v2:
> - support memory hotplug case.
> - uses static address for vmem_map (ia64)
> - added optimized pfn_valid() for ia64 (experimental)
>
> Intro:
> When using SPARSEMEM, pfn_to_page()/page_to_pfn() accesses global big table
> of mem_section. if SPARSEMEM_EXTREME, this is 2-level table lookup.
Did you gather any performance numbers comparing
VIRTUAL_MEM_MAP+SPARSEMEM to SPARSEMEM+EXTREME? I did some quick but
inconclusive (small machine) ones when you first posted. There was
perhaps a slight degradation in VIRTUAL_MEM_MAP+SPARSEMEM.
bob
>
> If we can map mem_section->mem_map in (virtually) linear address, we can expect
> optimzed pfn <-> page translation.
>
> Virtual mem_map is not useful for 32bit archs. This uses huge virtual
> address range.
>
> -Kame
next prev parent reply other threads:[~2006-12-10 19:47 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-08 6:56 [RFC] [PATCH] virtual memmap on sparsemem v3 [0/4] introduction KAMEZAWA Hiroyuki
2006-12-08 7:01 ` [RFC] [PATCH] virtual memmap on sparsemem v3 [1/4] map and unmap KAMEZAWA Hiroyuki
2006-12-09 0:28 ` Andrew Morton
2006-12-09 2:43 ` KAMEZAWA Hiroyuki
2006-12-09 4:52 ` KAMEZAWA Hiroyuki
2006-12-08 7:04 ` [RFC] [PATCH] virtual memmap on sparsemem v3 [2/4] generic virtual mem_map on sparsemem KAMEZAWA Hiroyuki
2006-12-09 12:05 ` Heiko Carstens
2006-12-09 13:17 ` KAMEZAWA Hiroyuki
2006-12-11 6:44 ` KAMEZAWA Hiroyuki
2006-12-08 7:07 ` [RFC] [PATCH] virtual memmap on sparsemem v3 [3/4] static virtual mem_map KAMEZAWA Hiroyuki
2006-12-09 0:30 ` Andrew Morton
2006-12-09 2:49 ` KAMEZAWA Hiroyuki
2006-12-09 3:33 ` Andrew Morton
2006-12-09 3:41 ` KAMEZAWA Hiroyuki
2006-12-09 4:53 ` KAMEZAWA Hiroyuki
2006-12-08 7:08 ` [RFC] [PATCH] virtual memmap on sparsemem v3 [4/4] ia64 support KAMEZAWA Hiroyuki
2006-12-09 4:55 ` KAMEZAWA Hiroyuki
2006-12-09 11:51 ` [RFC] [PATCH] virtual memmap on sparsemem v3 [0/4] introduction Heiko Carstens
2006-12-09 13:21 ` KAMEZAWA Hiroyuki
2006-12-10 19:47 ` Bob Picco [this message]
2006-12-11 0:43 ` KAMEZAWA Hiroyuki
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=20061210194730.GA10629@localhost \
--to=bob.picco@hp.com \
--cc=akpm@osdl.org \
--cc=apw@shadowen.org \
--cc=clameter@engr.sgi.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.