> On juin 27, 2016, 5 après-midi, 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. > > Nikos Nikoleris wrote: > 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 Nikoleris wrote: > Sophiane, how are things progressing? It would be really great to get > done with this and commit it.
Hi Nikos, I was and I am still quite busy with some other work I have to finish. But I will try to publish the new version of the patch as soon as possible. Sorry for the delay. - Sophiane ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3502/#review8441 ----------------------------------------------------------- On juin 28, 2016, 1:06 après-midi, Sophiane SENNI wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3502/ > ----------------------------------------------------------- > > (Updated juin 28, 2016, 1:06 après-midi) > > > 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