Re: [Gems-users] Why should Opal issue speculative store to ruby?

[Luke Yen <lyen@xxxxxxxxxxx>]

Hi,

  Concering stores only:

   You are correct in noticing that there is store permission prefetching
occuring when the address is ready but the data is not yet ready.  I
believe the original intent was to overlap some latency (albeit not alot)
between waiting for the data to be computed and for the actual request to
be sent.

  On Ruby's side, I believe most protocols do not treat prefetches as a
different request type than demand requests.  However Opal doesn't receive
callbacks notifying when they have completed, unlike for demand requests,
so Ruby is free to drop prefetches anytime it wants.

  Although stores and loads are issued out-of-order, they must be retired
in-order, and any in-flight load-store dependencies (including RAW) are
tracked through the LSQ.

  Memory consistency:

  Memory consistency is a related but separate issue.  There is a
window of vulnerability between the time the load/store is issued (when
operands are ready) and when the load/store commits (ie at the head of the
ROB).  Opal doesn't check the LSQ for external coherence requests so it
will not detect any incoming invalidates before loads and stores commit.

  However any of these race conditions, as well as any SC violations, will
result in deviations between Opal and Simics state, and the amount of deviations is printed in Opal's
stats file.  We do not see a large amount of these deviations, so we have
not attempted to fix this problem.

  Luke



On Tue, 21 Nov 2006, [utf-8] ���^P wrote:

> Thanks for your reply.
> This explanation, just as I expected, may be the only one that can justify Opal's behavior. But it doesn't meet the code quite well. Or at least the code is misleading. Remember, in method 'store_inst_t::continueExecution()', there is a branch that explicitly issues a pre-fetch to ruby when the value is not ready yet.
> And the README.memory_consistency file also gives wrong information:
> Quote:
>    2) Stores are executed out of program order.  Stores are not treated as a special type of instruction, and thus will execute when its operands are ready (both address and data to be stored).  Note this is not the same as a cache line write permission prefetch, which do occur for stores which have its address computed but the data to be stored is not ready yet.
> ________________________________________
> > From: gems-users-bounces@xxxxxxxxxxx [mailto:gems-users-bounces@xxxxxxxxxxx] On Behalf Of Dan Gibson
> > Sent: Monday, November 20, 2006 10:46 PM
> > To: Gems Users
> > Subject: Re: [Gems-users] Why should Opal issue speculative store to ruby?
> >
> > Since Ruby doesn't actually store values, you can think of the "issue" of the store as a permission prefetch. Ruby only tracks cache line metastate anyway (it doesn't need to track actual values in the cache). The store remains resident in the LSQ until commit-time. It is true that "issuing" the store changes the Ruby statistics-- but store prefetching isn't really pollution, merely a possible optimization from an out-of-order core, and it is consistent to use store prefetching, provided that the actual store value doesn't appear to other processors before commit-time.
> >
> > > Hi,
> > >          After reading the source code of Opal, I come to the point that it doesn’t pay any attention to store instructions in mis-predicted branch. It may have issued load/stores to Ruby when the pipeline has been flashed.
> > >     Yes, I understand that Opal was designed to be a very aggressive optimistic OOO processor. I find it ok to even issue stores out of order, and so is to   issue loads speculatively. But it’s unacceptable to me if the stores are speculatively issued to Ruby, which will pollute the statistics of Ruby and be impractical to real-world systems.
> > >      Can anybody prove me wrong or explain why it was designed like 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.
>
>