From: "Martin J. Bligh" <mbligh@google.com>
To: Andi Kleen <ak@suse.de>
Cc: Christoph Lameter <clameter@sgi.com>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
linux-mm@kvack.org,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>,
Andy Whitcroft <apw@shadowen.org>apw, please
Subject: Re: [PATCH 1/4] x86_64: Switch to SPARSE_VIRTUAL
Date: Mon, 02 Apr 2007 08:51:56 -0700 [thread overview]
Message-ID: <4611269C.2000709@google.com> (raw)
In-Reply-To: <200704021744.39880.ak@suse.de>
him on this stuff ?
Andi Kleen wrote:
> On Monday 02 April 2007 17:37, Christoph Lameter wrote:
>> On Sun, 1 Apr 2007, Andi Kleen wrote:
>>
>>> Hmm, this means there is at least 2MB worth of struct page on every node?
>>> Or do you have overlaps with other memory (I think you have)
>>> In that case you have to handle the overlap in change_page_attr()
>> Correct. 2MB worth of struct page is 128 mb of memory. Are there nodes
>> with smaller amounts of memory?
>
> Yes the discontigmem minimum is 64MB and there are some setups
> (mostly with numa emulation) where you end up with nodes that small.
We're actually using numa emulation to do real (container) things with.
However, 128MB is still pretty small for that ... and worst case, we
just waste 1MB for a 64MB node, right? Which isn't beautiful, but
doesn't seem like the end of the world for an obscure corner case.
>>> Do you have any benchmarks numbers to prove it? There seem to be a few
>>> benchmarks where the discontig virt_to_page is a problem
>>> (although I know ways to make it more efficient), and sparsemem
>>> is normally slower. Still some numbers would be good.
>> You want a benchmark to prove that the removal of memory references and
>> code improves performance?
>
> You're just moving them into MMU, not really removing it. And need more TLB entries.
> It might be faster or it might not. There are some unexpected issues, like most x86-64
> CPUs have a quite small number of large TLBs so you can get thrashing etc.
>
> So numbers with TLB intensive workloads would be good.
There's also the possibility it just doesn't make enough difference
to affect a real benchmark ...
M.
--
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 15:51 UTC|newest]
Thread overview: 46+ 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 ` [PATCH 1/4] x86_64: Switch to SPARSE_VIRTUAL Christoph Lameter
2007-04-01 7:11 ` Christoph Lameter
2007-04-01 10:46 ` Andi Kleen
2007-04-02 15:37 ` Christoph Lameter
2007-04-02 15:44 ` Andi Kleen
2007-04-02 15:51 ` Martin J. Bligh [this message]
2007-04-02 15:54 ` Christoph Lameter
2007-04-02 17:14 ` Andi Kleen
2007-04-02 17:34 ` Christoph Lameter
2007-04-02 19:54 ` Dave Hansen
2007-04-02 20:11 ` Christoph Lameter
2007-04-02 20:13 ` Dave Hansen
2007-04-02 20:30 ` Christoph Lameter
2007-04-02 20:38 ` Martin Bligh
2007-04-02 20:51 ` Christoph Lameter
2007-04-05 11:50 ` Andy Whitcroft
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:18 ` Andi Kleen
2007-04-09 16:40 ` William Lee Irwin III
2007-04-09 17:16 ` Christoph Lameter
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:28 ` Christoph Lameter
2007-04-02 21:43 ` Martin Bligh
2007-04-02 21:56 ` Dave Hansen
2007-04-02 22:29 ` Christoph Lameter
2007-04-02 22:31 ` Andi Kleen
2007-04-02 22:37 ` Christoph Lameter
2007-04-02 22:41 ` Martin Bligh
2007-04-02 22:49 ` Christoph Lameter
2007-04-02 22:52 ` Martin Bligh
2007-04-05 12:07 ` Andy Whitcroft
2007-04-04 21:27 ` Bob Picco
2007-04-04 22:38 ` Christoph Lameter
2007-04-02 23:03 ` Bjorn Helgaas
2007-04-02 15:44 ` 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 21:00 ` Christoph Lameter
2007-04-02 21:22 ` Dave Hansen
2007-04-02 21:31 ` Christoph Lameter
2007-04-02 21:42 ` Dave Hansen
2007-04-02 21:53 ` Christoph Lameter
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=4611269C.2000709@google.com \
--to=mbligh@google.com \
--cc=ak@suse.de \
--cc=apw@shadowen.org \
--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 \
/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