> On July 27, 2016, 4:52 p.m., 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? > > Sophiane SENNI wrote: > 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 ? > > Andreas Hansson wrote: > blk->whenReady represents the fact that the block is technically not > available yet. Due to how we do timing modelling we annotate the block when > it arrives, but have to remember when it is _actually_ availalbe. Thus, > anything we do here should add on top of the blk->whenReady. Same for fa_lru > > Sophiane SENNI wrote: > Ok. So if I understood, we actually need to apply the accessLatency on > top of the blk->whenReady. Hence, the good code would be as follows: > > if (blk->whenReady > curTick() > && cache->ticksToCycles(blk->whenReady - curTick()) > > accessLatency) { > lat = cache->ticksToCycles(blk->whenReady - curTick()) + > accessLatency; > } > > Does this change make more sense ?
Yes. Also, could you add a comment to explain what is happening here. > On July 27, 2016, 4:52 p.m., 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? > > Sophiane SENNI wrote: > I we care about blk->whenReady in base_set_assoc.hh, I assume we have > also to care about it here. Agreed. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3502/#review8552 ----------------------------------------------------------- On Oct. 24, 2016, 2:56 p.m., Sophiane SENNI wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3502/ > ----------------------------------------------------------- > > (Updated Oct. 24, 2016, 2:56 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11688:9dba209f1590 > --------------------------- > 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/base.cc 4aac82f10951 > src/mem/cache/tags/base_set_assoc.hh 4aac82f10951 > src/mem/cache/tags/fa_lru.cc 4aac82f10951 > configs/common/Caches.py 4aac82f10951 > configs/common/O3_ARM_v7a.py 4aac82f10951 > configs/example/arm/devices.py 4aac82f10951 > configs/learning_gem5/part1/caches.py 4aac82f10951 > src/mem/cache/Cache.py 4aac82f10951 > src/mem/cache/base.hh 4aac82f10951 > src/mem/cache/base.cc 4aac82f10951 > src/mem/cache/tags/Tags.py 4aac82f10951 > src/mem/cache/tags/base.hh 4aac82f10951 > > Diff: http://reviews.gem5.org/r/3502/diff/ > > > Testing > ------- > > Tested using --Debug-flags=Cache > > > Thanks, > > Sophiane SENNI > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
