From: Dave Hansen <hansendc@us.ibm.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
Martin Bligh <mbligh@google.com>,
linux-mm@kvack.org,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH 1/4] x86_64: Switch to SPARSE_VIRTUAL
Date: Mon, 02 Apr 2007 12:54:56 -0700 [thread overview]
Message-ID: <1175543696.22373.51.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0704020851300.30394@schroedinger.engr.sgi.com>
On Mon, 2007-04-02 at 08:54 -0700, Christoph Lameter wrote:
> > BTW there is no guarantee the node size is a multiple of 128MB so
> > you likely need to handle the overlap case. Otherwise we can
> > get cache corruptions
>
> How does sparsemem handle that?
It doesn't. :)
In practice, this situation never happens because we don't have any
actual architectures that have any node boundaries on less than
MAX_ORDER, and the section size is at least MAX_ORDER. If we *did* have
this, then the page allocator would already be broken for these
nodes. ;)
So, this SPARSE_VIRTUAL does introduce a new dependency, which Andi
calculated above. But, in reality, I don't think it's a big deal. Just
to spell it out a bit more, if this:
VMEMMAP_MAPPING_SIZE/sizeof(struct page) * PAGE_SIZE
(where VMEMMAP_MAPPING_SIZE is PMD_SIZE in your case) is any larger than
the granularity on which your NUMA nodes are divided, then you might
have a problem with mem_map for one NUMA node getting allocated on
another.
It might be worth a comment, or at least some kind of WARN_ON().
Perhaps we can stick something in online_page() to check if:
page_to_nid(page) == page_to_nid(virt_to_page(page))
-- Dave
WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <hansendc@us.ibm.com>
To: Christoph Lameter <clameter@sgi.com>
Cc: Andi Kleen <ak@suse.de>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
Martin Bligh <mbligh@google.com>,
linux-mm@kvack.org,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Subject: Re: [PATCH 1/4] x86_64: Switch to SPARSE_VIRTUAL
Date: Mon, 02 Apr 2007 12:54:56 -0700 [thread overview]
Message-ID: <1175543696.22373.51.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0704020851300.30394@schroedinger.engr.sgi.com>
On Mon, 2007-04-02 at 08:54 -0700, Christoph Lameter wrote:
> > BTW there is no guarantee the node size is a multiple of 128MB so
> > you likely need to handle the overlap case. Otherwise we can
> > get cache corruptions
>
> How does sparsemem handle that?
It doesn't. :)
In practice, this situation never happens because we don't have any
actual architectures that have any node boundaries on less than
MAX_ORDER, and the section size is at least MAX_ORDER. If we *did* have
this, then the page allocator would already be broken for these
nodes. ;)
So, this SPARSE_VIRTUAL does introduce a new dependency, which Andi
calculated above. But, in reality, I don't think it's a big deal. Just
to spell it out a bit more, if this:
VMEMMAP_MAPPING_SIZE/sizeof(struct page) * PAGE_SIZE
(where VMEMMAP_MAPPING_SIZE is PMD_SIZE in your case) is any larger than
the granularity on which your NUMA nodes are divided, then you might
have a problem with mem_map for one NUMA node getting allocated on
another.
It might be worth a comment, or at least some kind of WARN_ON().
Perhaps we can stick something in online_page() to check if:
page_to_nid(page) == page_to_nid(virt_to_page(page))
-- Dave
--
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:[~2007-04-02 19:55 UTC|newest]
Thread overview: 92+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-01 7:10 [PATCH 1/2] Generic Virtual Memmap suport for SPARSEMEM Christoph Lameter
2007-04-01 7:10 ` Christoph Lameter
2007-04-01 7:10 ` [PATCH 1/4] x86_64: Switch to SPARSE_VIRTUAL Christoph Lameter
2007-04-01 7:10 ` Christoph Lameter
2007-04-01 7:11 ` Christoph Lameter
2007-04-01 7:11 ` Christoph Lameter
2007-04-01 10:46 ` Andi Kleen
2007-04-01 10:46 ` Andi Kleen
2007-04-02 15:37 ` Christoph Lameter
2007-04-02 15:37 ` Christoph Lameter
2007-04-02 15:44 ` Andi Kleen
2007-04-02 15:44 ` Andi Kleen
2007-04-02 15:51 ` Martin J. Bligh
2007-04-02 15:51 ` Martin J. Bligh
2007-04-02 15:54 ` Christoph Lameter
2007-04-02 15:54 ` Christoph Lameter
2007-04-02 17:14 ` Andi Kleen
2007-04-02 17:14 ` Andi Kleen
2007-04-02 17:34 ` Christoph Lameter
2007-04-02 17:34 ` Christoph Lameter
2007-04-02 19:54 ` Dave Hansen [this message]
2007-04-02 19:54 ` Dave Hansen
2007-04-02 20:11 ` Christoph Lameter
2007-04-02 20:11 ` Christoph Lameter
2007-04-02 20:13 ` Dave Hansen
2007-04-02 20:13 ` Dave Hansen
2007-04-02 20:30 ` Christoph Lameter
2007-04-02 20:30 ` Christoph Lameter
2007-04-02 20:38 ` Martin Bligh
2007-04-02 20:38 ` Martin Bligh
2007-04-02 20:51 ` Christoph Lameter
2007-04-02 20:51 ` Christoph Lameter
2007-04-05 11:50 ` Andy Whitcroft
2007-04-05 11:50 ` Andy Whitcroft
2007-04-05 18:27 ` Christoph Lameter
2007-04-05 18:27 ` Christoph Lameter
2007-04-07 22:06 ` [PATCH 1/4] x86_64: (SPARSE_VIRTUAL doubles sparsemem speed) Christoph Lameter
2007-04-07 22:06 ` Christoph Lameter
2007-04-07 22:18 ` Andi Kleen
2007-04-07 22:18 ` Andi Kleen
2007-04-09 16:40 ` William Lee Irwin III
2007-04-09 16:40 ` William Lee Irwin III
2007-04-09 17:16 ` Christoph Lameter
2007-04-09 17:16 ` Christoph Lameter
2007-04-09 18:20 ` William Lee Irwin III
2007-04-09 18:20 ` William Lee Irwin III
2007-04-02 21:08 ` [PATCH 1/4] x86_64: Switch to SPARSE_VIRTUAL Dave Hansen
2007-04-02 21:08 ` Dave Hansen
2007-04-02 21:28 ` Christoph Lameter
2007-04-02 21:28 ` Christoph Lameter
2007-04-02 21:43 ` Martin Bligh
2007-04-02 21:43 ` Martin Bligh
2007-04-02 21:56 ` Dave Hansen
2007-04-02 21:56 ` Dave Hansen
2007-04-02 22:29 ` Christoph Lameter
2007-04-02 22:29 ` Christoph Lameter
2007-04-02 22:31 ` Andi Kleen
2007-04-02 22:31 ` Andi Kleen
2007-04-02 22:37 ` Christoph Lameter
2007-04-02 22:37 ` Christoph Lameter
2007-04-02 22:41 ` Martin Bligh
2007-04-02 22:41 ` Martin Bligh
2007-04-02 22:49 ` Christoph Lameter
2007-04-02 22:49 ` Christoph Lameter
2007-04-02 22:52 ` Martin Bligh
2007-04-02 22:52 ` Martin Bligh
2007-04-05 12:07 ` Andy Whitcroft
2007-04-05 12:07 ` Andy Whitcroft
2007-04-04 21:27 ` Bob Picco
2007-04-04 21:27 ` Bob Picco
2007-04-04 22:38 ` Christoph Lameter
2007-04-04 22:38 ` Christoph Lameter
2007-04-02 23:03 ` Bjorn Helgaas
2007-04-02 23:03 ` Bjorn Helgaas
2007-04-02 15:44 ` Christoph Lameter
2007-04-02 15:44 ` Christoph Lameter
2007-04-02 16:18 ` Christoph Lameter
2007-04-02 16:18 ` Christoph Lameter
2007-04-02 20:50 ` [PATCH 1/2] Generic Virtual Memmap suport for SPARSEMEM Dave Hansen
2007-04-02 20:50 ` Dave Hansen
2007-04-02 21:00 ` Christoph Lameter
2007-04-02 21:00 ` Christoph Lameter
2007-04-02 21:22 ` Dave Hansen
2007-04-02 21:22 ` Dave Hansen
2007-04-02 21:31 ` Christoph Lameter
2007-04-02 21:31 ` Christoph Lameter
2007-04-02 21:42 ` Dave Hansen
2007-04-02 21:42 ` Dave Hansen
2007-04-02 21:53 ` Christoph Lameter
2007-04-02 21:53 ` Christoph Lameter
2007-04-02 22:05 ` Dave Hansen
2007-04-02 22:05 ` Dave Hansen
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=1175543696.22373.51.camel@localhost.localdomain \
--to=hansendc@us.ibm.com \
--cc=ak@suse.de \
--cc=clameter@sgi.com \
--cc=kamezawa.hiroyu@jp.fujitsu.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mbligh@google.com \
/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.