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 --]
next prev 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.