From: Hubertus Franke <frankeh@watson.ibm.com>
To: "David S. Miller" <davem@redhat.com>,
davidm@hpl.hp.com, davidm@napali.hpl.hp.com
Cc: torvalds@transmeta.com, gh@us.ibm.com, Martin.Bligh@us.ibm.com,
wli@holomorpy.com, linux-kernel@vger.kernel.org
Subject: Re: large page patch (fwd) (fwd)
Date: Sun, 4 Aug 2002 13:25:42 -0400 [thread overview]
Message-ID: <200208041325.42210.frankeh@watson.ibm.com> (raw)
In-Reply-To: <20020803.173111.78037842.davem@redhat.com>
On Saturday 03 August 2002 08:31 pm, David S. Miller wrote:
> From: David Mosberger <davidm@napali.hpl.hp.com>
> Date: Sat, 3 Aug 2002 12:41:33 -0700
>
> It appears that Juan Navarro, the primary author behind the Rice
> project, is working on breaking down the superpage benefits they
> observed. That would tell us how much benefit is due to page-coloring
> and how much is due to TLB effects. Here in our lab, we do have some
> (weak) empirical evidence that some of the SPECint benchmarks benefit
> primarily from page-coloring, but clearly there are others that are
> TLB limited.
>
> There was some comparison done between large-page vs. plain
> page coloring for a bunch of scientific number crunchers.
>
> Only one benefitted from page coloring and not from TLB
> superpage use.
>
I would expect that from scientific apps, which often go through their
dataset in a fairy regular pattern. If sequential, then page coloring
is at its best, because your cache can become the limiting factor, if
you can't squeeze data into the cache due to false sharing in the same
cache class.
The way I see page coloring is that any hard work done in virtual space
(either by compiler or by app writer [ latter holds for numerical apps ])
to be cache friendly, is not circumvented by a <stupid> physical page
assignment by the OS that leads to less than complete cache utilization.
That's why the cache index bits from the address are carried over or
are kept the same in virtual and physical address. That's the purpose of
page coloring.....
This regular access pattern is not necessarily true in apps like JVM or other
object oriented code where data accesses can be less predictive. There page
coloring might not help you at all.
> The ones that benefitted from both coloring and superpages, the
> superpage gain was about equal to the coloring gain. Basically,
> superpages ended up giving the necessary coloring :-)
>
> Search for the topic "Areas for superpage discussion" in the
> sparclinux@vger.kernel.org list archives, it has pointers to
> all the patches and test programs involved.
--
-- Hubertus Franke (frankeh@watson.ibm.com)
next prev parent reply other threads:[~2002-08-04 17:24 UTC|newest]
Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E17ahdi-0001RC-00@w-gerrit2>
2002-08-02 19:34 ` Linus Torvalds
2002-08-03 3:19 ` David Mosberger
2002-08-03 3:32 ` Linus Torvalds
2002-08-03 4:17 ` David Mosberger
2002-08-03 4:26 ` Linus Torvalds
2002-08-03 4:39 ` David Mosberger
2002-08-03 5:20 ` David S. Miller
2002-08-03 17:35 ` Linus Torvalds
2002-08-03 19:30 ` David Mosberger
2002-08-03 19:43 ` Linus Torvalds
2002-08-03 21:18 ` David Mosberger
2002-08-03 21:54 ` Hubertus Franke
2002-08-04 0:35 ` David S. Miller
2002-08-04 2:25 ` David Mosberger
2002-08-04 17:19 ` Hubertus Franke
2002-08-09 15:20 ` Daniel Phillips
2002-08-09 15:56 ` Linus Torvalds
2002-08-09 16:15 ` Daniel Phillips
2002-08-09 16:31 ` Rik van Riel
2002-08-09 18:08 ` Daniel Phillips
2002-08-09 16:51 ` Linus Torvalds
2002-08-09 17:11 ` Daniel Phillips
2002-08-09 16:27 ` Rik van Riel
2002-08-09 16:52 ` Linus Torvalds
2002-08-09 17:40 ` yodaiken
2002-08-09 19:15 ` Rik van Riel
2002-08-09 21:20 ` Linus Torvalds
2002-08-09 21:19 ` Marcin Dalecki
2002-08-09 17:46 ` Bill Rugolsky Jr.
2002-08-12 9:23 ` Helge Hafting
2002-08-13 3:15 ` Bill Davidsen
2002-08-13 3:31 ` Rik van Riel
2002-08-13 7:28 ` Helge Hafting
2002-08-09 21:38 ` Andrew Morton
2002-08-10 18:20 ` Eric W. Biederman
2002-08-10 18:59 ` Daniel Phillips
2002-08-10 19:55 ` Rik van Riel
2002-08-10 19:54 ` Eric W. Biederman
2002-08-09 18:32 ` Hubertus Franke
2002-08-09 18:43 ` Daniel Phillips
2002-08-09 19:17 ` Hubertus Franke
2002-08-11 20:30 ` Alan Cox
2002-08-11 22:33 ` Daniel Phillips
2002-08-11 22:55 ` Linus Torvalds
2002-08-11 22:56 ` Linus Torvalds
2002-08-11 23:36 ` William Lee Irwin III
2002-08-12 0:46 ` Alan Cox
2002-08-11 23:42 ` Rik van Riel
2002-08-11 23:50 ` Larry McVoy
2002-08-12 8:22 ` Daniel Phillips
2002-08-13 8:40 ` Rob Landley
2002-08-13 15:06 ` Alan Cox
2002-08-13 11:36 ` Rob Landley
2002-08-13 16:51 ` Linus Torvalds
2002-08-13 12:53 ` Rob Landley
2002-08-13 17:14 ` Ruth Ivimey-Cook
2002-08-13 17:29 ` Rik van Riel
2002-08-13 13:18 ` Rob Landley
2002-08-13 18:32 ` Linus Torvalds
2002-08-13 13:50 ` Rob Landley
2002-08-13 17:45 ` Alexander Viro
2002-08-13 17:55 ` Linus Torvalds
2002-08-13 17:59 ` Rik van Riel
2002-08-13 13:35 ` Rob Landley
2002-08-13 19:12 ` Daniel Phillips
2002-08-22 12:03 ` bill davidsen
[not found] ` <Pine.LNX.4.44.0208130942130.7411-100000@home.transmeta.com >
2002-08-13 18:46 ` large page patch (fwd) Mike Galbraith
2002-08-11 23:44 ` large page patch (fwd) (fwd) Daniel Phillips
2002-08-13 8:51 ` Rob Landley
2002-08-13 16:47 ` Daniel Phillips
2002-08-13 13:09 ` Rob Landley
2002-08-11 23:15 ` Larry McVoy
2002-08-12 1:26 ` Linus Torvalds
2002-08-12 5:05 ` Larry McVoy
2002-08-12 10:31 ` Alan Cox
2002-08-04 0:28 ` David S. Miller
2002-08-04 17:31 ` Hubertus Franke
2002-08-04 18:38 ` Linus Torvalds
2002-08-04 19:23 ` Andrew Morton
2002-08-04 19:28 ` Linus Torvalds
2002-08-05 5:42 ` David S. Miller
2002-08-04 19:30 ` Hubertus Franke
2002-08-04 20:23 ` William Lee Irwin III
2002-08-05 16:59 ` David Mosberger
2002-08-05 17:21 ` Hubertus Franke
2002-08-05 21:10 ` Jamie Lokier
2002-08-04 19:41 ` Rik van Riel
2002-08-05 5:40 ` David S. Miller
2002-08-03 18:41 ` Hubertus Franke
2002-08-03 19:39 ` Linus Torvalds
2002-08-04 0:32 ` David S. Miller
2002-08-03 19:41 ` David Mosberger
2002-08-03 20:53 ` Hubertus Franke
2002-08-03 21:26 ` David Mosberger
2002-08-03 21:50 ` Hubertus Franke
2002-08-04 0:34 ` David S. Miller
2002-08-04 0:31 ` David S. Miller
2002-08-04 17:25 ` Hubertus Franke [this message]
[not found] <200208041331.24895.frankeh@watson.ibm.com.suse.lists.linux.kernel>
[not found] ` <Pine.LNX.4.44.0208041131380.10314-100000@home.transmeta.com.suse.lists.linux.kernel>
[not found] ` <3D4D7F24.10AC4BDB@zip.com.au.suse.lists.linux.kernel>
2002-08-04 20:20 ` Andi Kleen
2002-08-04 23:51 ` Eric W. Biederman
2002-08-05 23:30 Seth, Rohit
2002-08-06 5:01 ` David Mosberger
2002-08-06 4:58 ` David S. Miller
2002-08-06 5:19 ` David Mosberger
2002-08-06 5:08 ` David S. Miller
2002-08-06 5:32 ` David Mosberger
2002-08-06 19:11 ` Hubertus Franke
2002-08-06 20:38 Luck, Tony
2002-08-06 21:03 ` Hubertus Franke
2002-08-09 17:51 Seth, Rohit
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=200208041325.42210.frankeh@watson.ibm.com \
--to=frankeh@watson.ibm.com \
--cc=Martin.Bligh@us.ibm.com \
--cc=davem@redhat.com \
--cc=davidm@hpl.hp.com \
--cc=davidm@napali.hpl.hp.com \
--cc=gh@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
--cc=wli@holomorpy.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 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®