Hydra is certainly an interesting proposal. However, when Sun
commercialized some of the ideas from Hydra as the Niagara chip, they
used a write-through L1 with a block-level coherence protocol. Below
is a snippet from their IEEE Micro article from the April/May 2005
issue:
"Niagara uses a simple cache coherence protocol. The L1 caches are write
through, with allocate on load and no-allocate on stores. L1 lines
are either
in valid or invalid states. The L2 cache maintains a directory that
shadows the
L1 tags. The L2 cache also interleaves data across banks at a 64-byte
granularity. A load that missed in an L1 cache (load miss) is
delivered to the
source bank of the L2 cache along with its replacement way from the
L1 cache.
There, the load miss address is entered in the corresponding L1 tag
location of
the directory, the L2 cache is accessed to get the missing line and
data is
then returned to the L1 cache. The directory thus maintains a
sharers list at
L1-line granularity. A subsequent store from a different or same L1
cache will
look up the directory and queue up invalidates to the L1 caches that
have the
line."
They continue to describe what is required to make this work with
memory consistency in their system that has 4 threads per core:
"Stores do not update the local caches until they have updated the L2
cache. During this time, the store can pass data to the same thread
but not to
other threads; therefore, a store attains global visibility in the L2
cache. The crossbar establishes memory order between transactions
from the same
and different L2 banks, and guarantees delivery of transactions to L1
caches in
the same order."
As GEMS really wasn't designed for simulating TLS type systems, I'm
not sure GEMS is the way to go.
- Milo
On Jun 18, 2007, at 8:14 AM, 郭锐 wrote:
In fact, I was inspired by a TLS system based on the Stanford Hydra
CMP.
I think it's more suitable to implement a TLS system base on an
updating
protocol. Currently I use a system modified from LogTM to do my
experiments.
And I found that it suffers badly from false sharing and the
performance
drops dramatically when the data dependences are high. And a updating
protocol fits this situation quite well. So I begin to search for a
simulation platform that supports updating protocol such as dragon.
PS: The Hydra CMP also uses a write-through L1 and a shared L2. I'm
wondering how much bandwidth would it be needed to support such a
configuration.
-----Original Message-----
From: gems-users-bounces@xxxxxxxxxxx
[mailto:gems-users-bounces@xxxxxxxxxxx]
On Behalf Of Milo Martin
Sent: Monday, June 18, 2007 2:17 PM
To: Gems Users
Subject: Re: [Gems-users] Do you have the plan to support the
Dragonprotocol
inGEMS?
I agree with Mike's assessment that update protocols are
challenging. However, I would strengthen his comment to say that
update protocols aren't just challenging in GEMS, they are
challenging to implement in *real* systems as well. The memory
consistency model issues become really complicated really quickly. I
think this is one of the main reasons that most real systems today
use invalidation-based cache coherence protocols. Sure, there are
some issues with write-through L1s to a shared L2 used in systems
such as IBM's Power4, but that isn't as bad as a full update
protocol. I just can't think of a example of a high-performance
multiprocessor with an update protocol built in the last decade (or
longer).
For this reason, the Ruby/SLICC part of GEMS explicitly focuses only
on block-level coherence (which usually implies invalidation-based
cache coherence). Modifying GEMS to support update-based coherence
could be done, but most of SLICC would need to be removed (or heavily
modified) to do so.
- Milo
On Jun 17, 2007, at 7:57 AM, Mike Marty wrote:
I think implementing any update protocol is a challenge in GEMS
because of
memory consistency issues. The Simics functional simulation
implements
sequential consistency, and this might be hard with an update
protocol
(especially without an atomic bus)
--Mike
----- Original Message -----
From: "??" <timmyguo@xxxxxxxxxxxxxxxx>
To: <gems-users@xxxxxxxxxxx>
Sent: Sunday, June 17, 2007 4:38 AM
Subject: [Gems-users] Do you have the plan to support the Dragon
protocol
inGEMS?
Dear GEMS TEAM,
I recently find that a dragon protocol simulation would be
beneficial to
my
research. And GEMS doesn't implement this. Do you have a plan on
this?
As far as I know, the SLICC language & compiler handles memory
transaction
in per-line basis. I think it's crucial for an updating protocol
to handle
transaction in per-word basis, which not only eliminates false
sharing but
also reduces bandwidth consumption. Do you have a plan to
implement this?
G.R.
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding
"site:https://lists.cs.wisc.edu/archive/gems-users/"; to your
search.
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding
"site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
--
Milo M. K. Martin (milom@xxxxxxxxxxxxx)
http://www.cis.upenn.edu/~milom/
Assistant Professor
Computer and Information Sciences Department
University of Pennsylvania
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding
"site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding
"site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
--
Milo M. K. Martin (milom@xxxxxxxxxxxxx)
http://www.cis.upenn.edu/~milom/
Assistant Professor
Computer and Information Sciences Department
University of Pennsylvania
|
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}