----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1791/#review4161 -----------------------------------------------------------
Ship it! Ship It! - Ali Saidi On March 24, 2013, 11:28 a.m., Mitch Hayenga wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1791/ > ----------------------------------------------------------- > > (Updated March 24, 2013, 11:28 a.m.) > > > Review request for Default. > > > Description > ------- > > 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. > > > Note #1: It seems the non-LRU tags completely ignore the whenReady field. I > assume these tag classes are currently non-functional. > Note #2: I don't have commit access, someone else will have to push this. > > > Diffs > ----- > > src/mem/cache/cache_impl.hh 0a4b702628bd > > Diff: http://reviews.gem5.org/r/1791/diff/ > > > Testing > ------- > > 1 billion instructions on spec2k6's gcc across various simpoints on an out of > order cpu. > > > Thanks, > > Mitch Hayenga > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
