It completely depends on what consistency model you're going for.
The current code doesn't support sequential consistency, but the
load-load ordering that is enforced is inline with ARMs ordering
requirements.
Ali
On 21.06.2012 17:09, Dibakar Gope wrote:
> Hi
All,
>
> I was skimming through the O3+Ruby portion of the current dev
repository code, that attempts to support load-load ordering for a
stronger consistency model. In existing code, L1 cache controller sends
a forward_eviction_to_cpu, which in turn set the hitExternalSnoop flag
of a load instruction (provided the load has not committed yet) through
checksnoop() function. The checkViolation() portion of the code says
that in order to be squashed and re-executed, that particular load
instruction has to see another supposedly older load that maps to the
same cache block (the first if () block). The code snippet is shown
below:
>
> lsq_unit_impl.hh
> checkViolations()
> ------------
> if
(inst_eff_addr2 >= ld_eff_addr1 && inst_eff_addr1 isLoad()) {
> // If
this load is to the same block as an external snoop
> // invalidate that
we've observed then the load needs to be
> // squashed as it could have
newer data
> if (ld_inst->hitExternalSnoop) {
> if (!memDepViolator ||
>
ld_inst->seqNum < memDepViolator->seqNum) {
> DPRINTF(LSQUnit, "Detected
fault with inst [sn:%lli] "
> "and [sn:%lli] at address %#xn",
>
inst->seqNum, ld_inst->seqNum, ld_eff_addr1);
> memDepViolator =
ld_inst;
> ++lsqMemOrderViolation;
> return new
GenericISA::M5PanicFault(
> "Detected fault with inst [sn:%lli] and "
>
"[sn:%lli] at address %#xn",
> inst->seqNum, ld_inst->seqNum,
ld_eff_addr1);
> }
> }
> // Otherwise, mark the load has a possible load
violation
> // and if we see a snoop before it's commited, we need to
squash
> ld_inst->possibleLoadViolation = true;
> DPRINTF(LSQUnit,
"Found possible load violaiton at addr: %#x"
> " between instructions
[sn:%lli] and [sn:%lli]n",
> inst_eff_addr1, inst->seqNum,
ld_inst->seqNum);
> } else {
> ---------------
> ---------------
>
>
In my understanding, if a snoop hits a younger load in lsq before it is
committed, it need to be re-executed without any constraints from
checkViolation() function to maintain stronger consistency. I was
talking about the following simple example:
> c0 c1
>
> St B Ld A
> St
A Ld B
>
> if Ld B in core1 is executed out-of-order and later sees a
snoop before commit, should not we re-execute Ld B without any
constraints from checkViolations() function? Am I missing something
completely over here?
>
> Regards,
> Dibakar
>
_______________________________________________
> gem5-users mailing
list
> gem5-users@gem5.org
>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
