mem: Fix cache latency bug
authorMitch Hayenga <mitch.hayenga+gem5@gmail.com>
Wed, 27 Mar 2013 23:36:09 +0000 (18:36 -0500)
committerMitch Hayenga <mitch.hayenga+gem5@gmail.com>
Wed, 27 Mar 2013 23:36:09 +0000 (18:36 -0500)
Fixes a latency calculation bug for accesses during a cache line fill.

Under a cache miss, before the line is filled, accesses to the cache are
associated with a MSHR and marked as targets.  Once the line fill completes,
MSHR target packets pay an additional latency of
"responseLatency + busSerializationLatency".  However, the "whenReady"
field of the cache line is only set to an additional delay of
"busSerializationLatency".  This lacks the responseLatency component of
the fill.  It is possible for accesses that occur on the cycle of
(or briefly after) the line fill to respond without properly paying the
responseLatency.  This also creates the situation where two accesses to the
same address may be serviced in an order opposite of how they were received
by the cache.  For stores to the same address, this means that although the
cache performs the stores in the order they were received, acknowledgements
may be sent in a different order.

Adding the responseLatency component to the whenReady field preserves the
penalty that should be paid and prevents these ordering issues.

Committed by: Nilay Vaish <nilay@cs.wisc.edu>

src/mem/cache/cache_impl.hh

index 2be41642d5de4b7ee764089d36c3460c491b1030..68b86b121abbcddf2c21f9fb6069b560cb9769b6 100644 (file)
@@ -1242,7 +1242,8 @@ Cache<TagStore>::handleFill(PacketPtr pkt, BlkType *blk,
         std::memcpy(blk->data, pkt->getPtr<uint8_t>(), blkSize);
     }
 
-    blk->whenReady = curTick() + pkt->busLastWordDelay;
+    blk->whenReady = curTick() + responseLatency * clockPeriod() +
+        pkt->busLastWordDelay;
 
     return blk;
 }