> On juil. 27, 2016, 4:52 après-midi, Andreas Hansson wrote: > > src/mem/cache/tags/Tags.py, line 57 > > <http://reviews.gem5.org/r/3502/diff/12/?file=57339#file57339line57> > > > > Why would the tags care about the data latency?
This is required to initialize the "accessLatency" variable in tags/base.cc If I am right, the "accessLatency" variable declared in tags/base.hh is used to consider the cache latency on every access (i.e. considering tags and data accesses). Previously, "accessLatency" was always assigned to "hit_latency". With this patch, "accessLatency" value is initialized according to the cache access mode (parallel or sequential). > On juil. 27, 2016, 4:52 après-midi, Andreas Hansson wrote: > > src/mem/cache/tags/base.hh, line 75 > > <http://reviews.gem5.org/r/3502/diff/12/?file=57340#file57340line75> > > > > Seems odd that the tags need to track this. Is this still the best > > division? Perhaps explain why it's here. This can be removed. We actually do not need it since data latency is already included in accessLatency. > On juil. 27, 2016, 4:52 après-midi, Andreas Hansson wrote: > > src/mem/cache/tags/base_set_assoc.hh, line 228 > > <http://reviews.gem5.org/r/3502/diff/12/?file=57342#file57342line228> > > > > Could you add a comment here? > > > > It seems to me this code is not right, as it checks if the data is > > technically written now, but we only need the data at time T. > > > > Should we not rather add the dataLatency to the blk->whenReady and then > > do the plus or max opteration? I actually don't really understand what this code represents, which was already present before applying the patch. Because it seems to show a case where the cache latency is greater than accessLatency, when the lat variable is updated as follows: lat = cache->ticksToCycles(blk->whenReady - curTick()) Can this situation actually occur ? > On juil. 27, 2016, 4:52 après-midi, Andreas Hansson wrote: > > src/mem/cache/tags/fa_lru.cc, line 188 > > <http://reviews.gem5.org/r/3502/diff/12/?file=57343#file57343line188> > > > > here we don't care about blk->whenReady? I we care about blk->whenReady in base_set_assoc.hh, I assume we have also to care about it here. - Sophiane ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3502/#review8552 ----------------------------------------------------------- On juil. 25, 2016, 1:16 après-midi, Sophiane SENNI wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3502/ > ----------------------------------------------------------- > > (Updated juil. 25, 2016, 1:16 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 > ----- > > src/mem/cache/tags/fa_lru.cc 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > configs/common/Caches.py 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/Cache.py 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/base.hh 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/base.cc 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/Tags.py 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/base.hh 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/base.cc 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/base_set_assoc.hh > 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
