On Wed, 19 Dec 2012, Arthur Perais wrote:
Hi all,
Correct me if I am wrong, but as I understand the code, for a store
instruction, the D-Cache is only accessed when the store writes back, that is
when it is at the head of the LSQ and has been committed and a port is
available.
Now, if there is a miss in the L1 (and possibly the L2), we have to suffer
all the miss latency, then do the write back. However, the effective address
of the store is computed at execute, meaning that we should be able to probe
the cache at execute to bring the line if it is not there. If it is, then we
only have to wait for the store to commit and write back.
I agree that the SQ is not on the critical path since stores are already
committed so they are not blocking other instructions. That is only when the
SQ has free entries. When it is full, hiding some of the miss latency allows
the store to writeback faster and release its slot in the SQ faster. I grant
you that this may not impact performance that much, however I am trying to
find a quick and dirty way to implement it to find out. For now, I am simply
issuing a HW Prefetch Request to the memory hierarchy at execute on behalf of
the store instruction. It appears to do the trick and to preserve
correctness. Yet, I am clearly no expert with the way memory works in gem5 so
if this sounds like something really stupid to do, please let me know. I
guess the "right" solution would be to create a new request type and insert
code to handle it in the proper places.
Seems fine to me. Coherence permissions can be obtained speculatively,
with out affecting correctness.
I also have another question which is x86-related. In O3, the needsTSO
variable of the LSQ is set only when the ISA is x86. As I understand it, it
forbids more than one store to be written back every cycle. Yet, if two ports
are available at any given cycle, why not write two? They will still be
written in-order...won't they?
It is not necessary that they would written in the same order. The memory
system is free to re-order them. This means that some other core may
observe the stores being carried out in the opposite order, violating TSO.
--
Nilay
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
