From: Paul Mackerras <paulus@samba.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andi Kleen <andi@firstfloor.org>,
David Miller <davem@davemloft.net>,
clameter@sgi.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org
Subject: Re: larger default page sizes...
Date: Thu, 27 Mar 2008 12:08:34 +1100 [thread overview]
Message-ID: <18410.62354.643308.84737@cargo.ozlabs.ibm.com> (raw)
In-Reply-To: <alpine.LFD.1.00.0803260854350.2775@woody.linux-foundation.org>
Linus Torvalds writes:
> On Wed, 26 Mar 2008, Paul Mackerras wrote:
> >
> > So the improvement in the user time is almost all due to the reduced
> > TLB misses (as one would expect). For the system time, using 64k
> > pages in the VM reduces it by about 21%, and using 64k hardware pages
> > reduces it by another 30%. So the reduction in kernel overhead is
> > significant but not as large as the impact of reducing TLB misses.
>
> I realize that getting the POWER people to accept that they have been
> total morons when it comes to VM for the last three decades is hard, but
> somebody in the POWER hardware design camp should (a) be told and (b) be
> really ashamed of themselves.
>
> Is this a POWER6 or what? Becasue 21% overhead from TLB handling on
> something like gcc shows that some piece of hardware is absolute crap.
You have misunderstood the 21% number. That number has *nothing* to
do with hardware TLB miss handling, and everything to do with how long
the generic Linux virtual memory code spends doing its thing (page
faults, setting up and tearing down Linux page tables, etc.). It
doesn't even have anything to do with the hash table (hardware page
table), because both cases are using 4k hardware pages. Thus in both
cases the TLB misses and hash-table misses would have been the same.
The *only* difference between the cases is the page size that the
generic Linux virtual memory code is using. With the 64k page size
our architecture-independent kernel code runs 21% faster.
Thus the 21% is not about the TLB or any hardware thing at all, it's
about the larger per-byte overhead of our kernel code when using the
smaller page size.
The thing you were ranting about -- hardware TLB handling overhead --
comes in at 5%, comparing 4k hardware pages to 64k hardware pages (444
seconds vs. 420 seconds user time for the kernel compile). And yes,
it's a POWER6.
Paul.
next prev parent reply other threads:[~2008-03-27 1:09 UTC|newest]
Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-21 6:17 [00/14] Virtual Compound Page Support V3 Christoph Lameter
2008-03-21 6:17 ` [01/14] vcompound: Return page array on vunmap Christoph Lameter
2008-03-21 6:17 ` [02/14] vcompound: pageflags: Add PageVcompound() Christoph Lameter
2008-03-21 6:17 ` [03/14] vmallocinfo: Support display of vcompound for a virtual compound page Christoph Lameter
2008-03-21 7:55 ` Eric Dumazet
2008-03-21 17:32 ` Christoph Lameter
2008-03-21 6:17 ` [04/14] vcompound: Core piece Christoph Lameter
2008-03-22 12:10 ` KOSAKI Motohiro
2008-03-24 18:28 ` Christoph Lameter
2008-03-21 6:17 ` [05/14] vcompound: Debugging aid Christoph Lameter
2008-03-21 6:17 ` [06/14] vcompound: Virtual fallback for sparsemem Christoph Lameter
2008-03-21 6:17 ` [07/14] vcompound: bit waitqueue support Christoph Lameter
2008-03-21 6:17 ` [08/14] vcompound: Fallback for zone wait table Christoph Lameter
2008-03-21 6:17 ` [09/14] vcompound: crypto: Fallback for temporary order 2 allocation Christoph Lameter
2008-03-21 6:17 ` [10/14] vcompound: slub: Use for buffer to correlate allocation addresses Christoph Lameter
2008-03-21 6:17 ` [11/14] vcompound: Fallbacks for order 1 stack allocations on IA64 and x86 Christoph Lameter
2008-03-21 7:25 ` David Miller
2008-03-21 8:39 ` Ingo Molnar
2008-03-21 17:33 ` Christoph Lameter
2008-03-21 19:02 ` Ingo Molnar
2008-03-21 19:04 ` Christoph Lameter
2008-03-21 17:40 ` Christoph Lameter
2008-03-21 21:57 ` David Miller
2008-03-24 18:27 ` Christoph Lameter
2008-03-24 20:37 ` larger default page sizes David Miller
2008-03-24 21:05 ` Christoph Lameter
2008-03-24 21:43 ` David Miller
2008-03-25 17:48 ` Christoph Lameter
2008-03-25 23:22 ` David Miller
2008-03-25 23:41 ` Peter Chubb
2008-03-25 23:49 ` David Miller
2008-03-26 0:25 ` Peter Chubb
2008-03-26 0:31 ` David Miller
2008-03-26 0:34 ` David Mosberger-Tang
2008-03-26 0:39 ` David Miller
2008-03-26 0:57 ` Peter Chubb
2008-03-26 4:16 ` John Marvin
2008-03-26 4:36 ` David Miller
2008-03-24 21:25 ` Luck, Tony
2008-03-24 21:46 ` David Miller
2008-03-25 3:29 ` Paul Mackerras
2008-03-25 4:15 ` David Miller
2008-03-25 11:50 ` Paul Mackerras
2008-03-25 23:32 ` David Miller
2008-03-25 23:49 ` Luck, Tony
2008-03-26 0:16 ` David Miller
2008-03-26 15:54 ` Nish Aravamudan
2008-03-26 17:05 ` Luck, Tony
2008-03-26 18:54 ` Mel Gorman
2008-03-25 12:05 ` Andi Kleen
2008-03-25 21:27 ` Paul Mackerras
2008-03-26 5:24 ` Paul Mackerras
2008-03-26 15:59 ` Linus Torvalds
2008-03-27 1:08 ` Paul Mackerras [this message]
2008-03-26 17:56 ` Christoph Lameter
2008-03-26 23:21 ` David Miller
2008-03-27 3:00 ` Paul Mackerras
2008-03-25 18:27 ` Dave Hansen
2008-03-24 21:13 ` [11/14] vcompound: Fallbacks for order 1 stack allocations on IA64 and x86 Luck, Tony
2008-03-25 17:42 ` Christoph Lameter
2008-03-25 19:09 ` Luck, Tony
2008-03-25 19:25 ` Christoph Lameter
2008-03-21 22:30 ` Andi Kleen
2008-03-24 19:53 ` Christoph Lameter
2008-03-25 7:51 ` Andi Kleen
2008-03-25 17:55 ` Christoph Lameter
2008-03-25 18:07 ` Andi Kleen
2008-03-21 6:17 ` [12/14] vcompound: Avoid vmalloc in e1000 driver Christoph Lameter
2008-03-21 17:27 ` Kok, Auke
2008-03-21 6:17 ` [13/14] vcompound: Use vcompound for swap_map Christoph Lameter
2008-03-21 21:25 ` Andi Kleen
2008-03-21 21:33 ` Christoph Lameter
2008-03-24 19:54 ` Christoph Lameter
2008-03-25 7:52 ` Andi Kleen
2008-03-25 17:45 ` Christoph Lameter
2008-03-25 17:55 ` Andi Kleen
2008-03-25 17:51 ` Christoph Lameter
2008-03-21 6:17 ` [14/14] vcompound: Avoid vmalloc for ehash_locks Christoph Lameter
2008-03-21 7:02 ` Eric Dumazet
2008-03-21 7:03 ` Christoph Lameter
2008-03-21 7:31 ` David Miller
2008-03-21 7:42 ` Eric Dumazet
2008-03-21 7:31 ` David Miller
2008-03-21 17:31 ` Christoph Lameter
2008-03-22 18:40 ` [00/14] Virtual Compound Page Support V3 Arjan van de Ven
2008-03-24 18:31 ` Christoph Lameter
2008-03-24 19:29 ` Christoph Lameter
2008-03-25 23:47 larger default page sizes J.C. Pizarro
2008-03-26 15:57 ` H. Peter Anvin
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=18410.62354.643308.84737@cargo.ozlabs.ibm.com \
--to=paulus@samba.org \
--cc=andi@firstfloor.org \
--cc=clameter@sgi.com \
--cc=davem@davemloft.net \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=torvalds@linux-foundation.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
all inboxes | Powered by JetHome®