----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2634/#review5836 -----------------------------------------------------------
Ship it! just some minor stuff, looks fine overall src/mem/cache/cache_impl.hh <http://reviews.gem5.org/r/2634/#comment5154> unnecessary blank line? src/mem/cache/tags/base_set_assoc.hh <http://reviews.gem5.org/r/2634/#comment5149> two semicolons src/mem/cache/tags/base_set_assoc.hh <http://reviews.gem5.org/r/2634/#comment5153> orthogonal to your change, but this is pretty awkward; I believe this should be equivalent: if (blk != NULL) { if (blk->whenReady > curTick()) { lat = std::max(cache->ticksToCycles(blk->whenReady - curTick()), accessLatency); } blk->refCount++; } - Steve Reinhardt On Feb. 5, 2015, 4:52 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2634/ > ----------------------------------------------------------- > > (Updated Feb. 5, 2015, 4:52 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10700:5499f76d3356 > --------------------------- > mem: Clarify usage of latency in the cache > > This patch adds some much-needed clarity in the specification of the > cache timing. For now, hit_latency and response_latency are kept as > top-level parameters, but the cache itself has a number of local > variables to better map the individual timing variables to different > behaviours (and sub-components). > > The introduced variables are: > - lookupLatency: latency of tag lookup, occuring on any access > - forwardLatency: latency that occurs in case of outbound miss > - fillLatency: latency to fill a cache block > We keep the existing responseLatency > > The forwardLatency is used by allocateInternalBuffer() for: > - MSHR allocateWriteBuffer (unchached write forwarded to WriteBuffer); > - MSHR allocateMissBuffer (cacheable miss in MSHR queue); > - MSHR allocateUncachedReadBuffer (unchached read allocated in MSHR > queue) > It is our assumption that the time for the above three buffers is the > same. Similarly, for snoop responses passing through the cache we use > forwardLatency. > > > Diffs > ----- > > src/mem/cache/base.hh 7639c17357dc > src/mem/cache/base.cc 7639c17357dc > src/mem/cache/cache_impl.hh 7639c17357dc > src/mem/cache/tags/base.hh 7639c17357dc > src/mem/cache/tags/base.cc 7639c17357dc > src/mem/cache/tags/base_set_assoc.hh 7639c17357dc > src/mem/cache/tags/base_set_assoc.cc 7639c17357dc > src/mem/cache/tags/fa_lru.hh 7639c17357dc > src/mem/cache/tags/fa_lru.cc 7639c17357dc > > Diff: http://reviews.gem5.org/r/2634/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
