Re: [Gems-users] Do you have the plan to support the DragonprotocolinGEMS?

[郭锐 <timmyguo@xxxxxxxxxxxxxxxx>]

Thanks for your detailed reply. I'll dig into the referenced paper to see
how it works.
And about TLS on GEMS, I succeeded in making it work. But the performance of
some applications (especially with those having heavy dependencies) is
limited by the protocol. That's why I posted this thread.

> -----Original Message-----
> From: gems-users-bounces@xxxxxxxxxxx
[mailto:gems-users-bounces@xxxxxxxxxxx]
> On Behalf Of Milo Martin
> Sent: Monday, June 18, 2007 11:43 PM
> To: Gems Users
> Subject: Re: [Gems-users] Do you have the plan to support the
> DragonprotocolinGEMS?
> 
> 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
> 
> 
> 
> _______________________________________________
> 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.