> On June 27, 2016, 5 p.m., Nikos Nikoleris wrote: > > src/mem/cache/tags/base_set_assoc.hh, line 218 > > <http://reviews.gem5.org/r/3502/diff/8/?file=56390#file56390line218> > > > > Would it make sense to move most of this code in the constructor? The > > flag sequentialAccess and the condition lookupLatency >= dataLantency > > shouldn't change during the simulation. > > Sophiane SENNI wrote: > I think this code should be left here. Because the total access latency > now depends on both tag_latency and data_latency, the value of the 'lat' > parameter specifying the access latency is not correct when the accessBlock() > function is called. As a result, the 'lat' value should be updated inside the > function depending on if it is a sequential or parallel access. > > Sophiane SENNI wrote: > Regarding your suggestion, I am agree with you that it would be better to > move the code in the constructor since as you mentioned the flag > sequentialAccess and the access latency value should not change during the > simulation. I will see how I can modify the patch accordingly.
Thanks for doing this! I think you could create a new variable in the base class (BaseTags) and use that as the latency on every access. In any case, in the code the latency is not dependent on the replacement policy. Mind though that if the access is a miss the latency should always be tagLatency, even when we've enabled the parallel access. We could also move the sequentialAccess variable to BaseCache although I am not sure how applicable a parallel lookup to the tag and the data array is for a fully associative cache. - Nikos ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3502/#review8441 ----------------------------------------------------------- On June 28, 2016, 1:06 p.m., Sophiane SENNI wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3502/ > ----------------------------------------------------------- > > (Updated June 28, 2016, 1:06 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11536:1a3a96d435ed > --------------------------- > mem: Split the hit_latency into tag_latency and data_latency > > If the cache access mode is parallel, i.e. "sequential_access" parameter > is set to "False", tags and data are accessed in parallel. Therefore, > the hit_latency is the maximum latency between tag_latency and > data_latency. On the other hand, if the cache access mode is > sequential, i.e. "sequential_access" parameter is set to "True", > tags and data are accessed sequentially. Therefore, the hit_latency > is the sum of tag_latency plus data_latency. > > > Diffs > ----- > > configs/common/Caches.py 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/Cache.py 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/base.hh 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/fa_lru.cc 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/fa_lru.hh 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/base_set_assoc.hh > 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/base.cc 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/base.hh 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/Tags.py 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/base.cc 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > > Diff: http://reviews.gem5.org/r/3502/diff/ > > > Testing > ------- > > Tested using --Debug-flags=Cache > > > Thanks, > > Sophiane SENNI > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
