All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Mosberger <davidm@napali.hpl.hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: [Linux-ia64] page size > 16KB
Date: Thu, 13 Mar 2003 18:05:22 +0000	[thread overview]
Message-ID: <marc-linux-ia64-105590709806079@msgid-missing> (raw)
In-Reply-To: <marc-linux-ia64-105590709806057@msgid-missing>

[-- Attachment #1: message body text --]
[-- Type: text/plain, Size: 1419 bytes --]

>>>>> On Wed, 12 Mar 2003 13:51:16 -0600, Mario Smarduch <cms063@email.mot.com> said:

  Mario> Hi David, I'm very curious about your statement regarding
  Mario> reproducible results - a desirable attribute for many
  Mario> applications in our case soft real-time predictability. With
  Mario> the caches on Itanium2 being highly associative, did you
  Mario> notice a dramatic change in reproducibility as you did in TLB
  Mario> efficiency? This is assuming a locked memory intensive
  Mario> application or this was too long ago for you to remember :)

Heh, I barely remember what I ate for dinner last night, so I
certainly don't remember what that application was about... ;-)

Apps with large arrays certainly can see significant variation due to
lack of page coloring in the kernel, even with high associativity.  I
ran a Monte Carlo simulation on this a while ago and attached the
results below.

As you can see, high associativity keeps page-coloring effects away up
until you occupy about 1.5-2MB (out of a 3MB cache).  So if you have,
say, a 3MB array, you'd clearly expect to see page-coloring effects.

The graph also shows that larger page sizes somewhat reduce the
negative effets of lack of page-coloring (not entirely intuitive, but
it's pretty complex as to what's going on, so it's not surprising that
intuition doesn't get us very far).

I should update the graph for Madison some day.

	--david


[-- Attachment #2: coll.pdf --]
[-- Type: application/pdf, Size: 7927 bytes --]

  parent reply	other threads:[~2003-03-13 18:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-12 16:38 [Linux-ia64] page size > 16KB Jan Schreckenbach
2003-03-12 16:55 ` Grant Grundler
2003-03-12 17:07 ` n0ano
2003-03-12 17:40 ` David Mosberger
2003-03-12 17:46 ` David Mosberger
2003-03-12 17:49 ` Jesse Barnes
2003-03-12 18:07 ` David Mosberger
2003-03-12 18:08 ` Grant Grundler
2003-03-12 18:24 ` Jesse Barnes
2003-03-12 19:51 ` Mario Smarduch
2003-03-13 18:05 ` David Mosberger [this message]
2003-03-13 20:44 ` Mario Smarduch
2003-03-14 12:33 ` Jan Schreckenbach
2003-03-14 15:51 ` Chen, Kenneth W
2003-03-14 17:33 ` Jesse Barnes
2003-03-14 18:00 ` Mario Smarduch
2003-03-14 18:17 ` Grant Grundler
2003-03-14 19:00 ` Jesse Barnes
2003-03-14 19:43 ` David Mosberger
2003-03-15  3:08 ` 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=marc-linux-ia64-105590709806079@msgid-missing \
    --to=davidm@napali.hpl.hp.com \
    --cc=linux-ia64@vger.kernel.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 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.