Re: [Gems-users] Memory Consistency with Opal

[Luke Yen <lyen@xxxxxxxxxxx>]

   Yes, Albert you are correct in your analysis.  In our current
release since all loads are checked in retireInstruction() that is
when non-SC completion of loads are found.  However, when it does
happen this non-SC execution does get deducted from the "Total
percentage correct" in the *.opal output file.  As you'll notice these
OoO memory instructions do not really affect correctness at all.  As
for timing, you are correct in saying that it will affect the timing,
since SC will most likely cause stall cycles while waiting for the
loads and stores to complete in program order.
  Also, keep in mind that Opal doesn't actually consult Ruby for the
actual data values it loads from memory.  Ruby is only used by Opal to
simulate the timing of loads and stores, while the actual values are read
using a Simics API call.
  For futher comments on this matter, you should look at
README.memory_consistency in the opal/ directory.
Basically what you have descibed is one area in which Opal
violates SC.  Another violation occurs in the grouping of loads and stores
in the MSHR, in which stores to the same address will be merged together
in the same MSHR entry.

   Luke

On Fri, 11 Mar 2005, Albert Meixner wrote:

> I have a question regarding the consistency model implemented by GEMS
> when running with Opal. So far I assumed it would be sequentially
> consistent, but there is an issue related to load ordering that make me
> uncertain.
>
> In Opal a load will access the cache as soon as the load address is
> available. This can easily lead to loads being performed out of order,
> especially when one load misses in the cache and a later load hits in
> the cache. Load reordering, however, is not allowed in sequential
> consistency. Of course, loads can be reordered speculatively, but I
> can't find any piece of code that checks if the speculation was correct.
>
> A short example to clarify my problem:
> Assume A, B are memory locations in different cache blocks and both
> initialized to 0
> Processor 1 executes:
> LD A, r1
> LD B, r2
>
> Processor 2 executes:
> ST B, 2
> ST A, 2
>
> In a sequentially consistent system, if r1==2 then r2==2. In Opal
> however, it seems possible that LD A misses the cache. LD B hits and
> receives the original value for B (=0). By the time processor 1 receives
> the block containing A, A can already have value 2, such that:
> r1 == 2, but r2 == 0.
>
> I am aware that this will be corrected when the registers are compared
> to Simics, but the timing will the be incorrect.
>
> Am I missing something?
>
> Thanks,
> Albert
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>