public inbox for linux-ia64@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Chubb <peterc@gelato.unsw.edu.au>
To: David Miller <davem@davemloft.net>
Cc: clameter@sgi.com, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, linux-ia64@vger.kernel.org,
	torvalds@linux-foundation.org, ianw@gelato.unsw.edu.au
Subject: Re: larger default page sizes...
Date: Tue, 25 Mar 2008 23:41:32 +0000	[thread overview]
Message-ID: <87tziu5q37.wl%peter@chubb.wattle.id.au> (raw)
In-Reply-To: <20080325.162244.61337214.davem@davemloft.net>

>>>>> "David" = David Miller <davem@davemloft.net> writes:

David> From: Christoph Lameter <clameter@sgi.com> Date: Tue, 25 Mar
David> 2008 10:48:19 -0700 (PDT)

>> On Mon, 24 Mar 2008, David Miller wrote:
>> 
>> > There are ways to get large pages into the process address space
>> for > compute bound tasks, without suffering the well known
>> negative side > effects of using larger pages for everything.
>> 
>> These hacks have limitations. F.e. they do not deal with I/O and
>> require application changes.

David> Transparent automatic hugepages are definitely doable, I don't
David> know why you think this requires application changes.

It's actually harder than it looks.  Ian Wienand just finished his
Master's project in this area, so we have *lots* of data.  The main
issue is that, at least on Itanium, you have to turn off the hardware
page table walker for hugepages if you want to mix superpages and
standard pages in the same region. (The long format VHPT isn't the
panacea we'd like it to be because the hash function it uses depends
on the page size).  This means that although you have fewer TLB misses
with larger pages, the cost of those TLB misses is three to four times
higher than with the standard pages.  In addition, to set up a large
page takes more effort... and it turns out there are few applications
where the cost is amortised enough, so on SpecCPU for example, some
tests improved performance slightly, some got slightly worse.

What we saw was essentially that we could almost eliminate DTLB misses,
other than the first, for a huge page.  For most applications, though,
the extra cost of that first miss, plus the cost of setting up the
huge page, was greater than the few hundred DTLB misses we avoided.

I'm expecting Ian to publish the full results soon.

Other architectures (where the page size isn't tied into the hash
function, so the hardware walked can be used for superpages) will have
different tradeoffs.

--
Dr Peter Chubb  http://www.gelato.unsw.edu.au  peterc AT gelato.unsw.edu.au
http://www.ertos.nicta.com.au           ERTOS within National ICT Australia

  reply	other threads:[~2008-03-25 23:41 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080321061726.782068299@sgi.com>
     [not found] ` <20080321.002502.223136918.davem@davemloft.net>
     [not found]   ` <Pine.LNX.4.64.0803211037140.18671@schroedinger.engr.sgi.com>
     [not found]     ` <20080321.145712.198736315.davem@davemloft.net>
2008-03-24 18:27       ` [11/14] vcompound: Fallbacks for order 1 stack allocations on 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 [this message]
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
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           ` [11/14] vcompound: Fallbacks for order 1 stack allocations on Christoph Lameter
2008-03-25 19:09             ` [11/14] vcompound: Fallbacks for order 1 stack allocations on IA64 and x86 Luck, Tony
2008-03-25 19:25               ` [11/14] vcompound: Fallbacks for order 1 stack allocations on Christoph Lameter

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=87tziu5q37.wl%peter@chubb.wattle.id.au \
    --to=peterc@gelato.unsw.edu.au \
    --cc=clameter@sgi.com \
    --cc=davem@davemloft.net \
    --cc=ianw@gelato.unsw.edu.au \
    --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