> On June 17, 2016, 7:57 a.m., Pierre-Yves Péneau wrote: > > I don't like the variable names, I think it's confusing especially in the > > Python part which is the user part. "lookup_latency" does not clearly > > refer to the tag lookup action , and "ram_latency" is also not very clear. > > Maybe something like "tag_latency" and "line_latency" could be better ? I > > think the two parts of a cache are well identified in this example. > > Sophiane SENNI wrote: > Hi Pierre-Yves, > > I am agree with you that the variable names in the Python part should not > be confusing for users. I reused the name from a previous discussion with > Andreas H. > We need feedback from other users to see what are the best annotation. In > Cache, there are tag arrays and data arrays, so maybe "tag_latency" and > "data_line_latency" could be a solution. > Any feedback from other gem5 users would be useful. > > Sophiane
Thanks for bringing this up. I vote for 'tag_latency' (or 'tag_lookup_latency') and 'data_latency'. If I understand correctly the patch has an impact on timing/stats only if sequential access is set to True and in that case only affects the hit latency. The timing on the miss path and allocation of mshr (mshr entry, mshr target, write buffer entry, ask for mem-side bus access) still uses the forwardLatency value. The forwardLatency used to be 'hit_latency' (at one point not so far in the past everything was 'hit_latency' anyway!). But this change makes a distinction between tag and data access and it is logical to make forward latency equal to tag_latency. If you also had this analysis in mind, please could you add a comment for forwardLatency somewhere? - Radhika ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3502/#review8419 ----------------------------------------------------------- On June 16, 2016, 6:55 p.m., Sophiane SENNI wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3502/ > ----------------------------------------------------------- > > (Updated June 16, 2016, 6:55 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11536:1a3a96d435ed > --------------------------- > cache: Split the hit latency into tag lookup latency and RAM access latency > > If the cache access mode is parallel ("sequential_access" parameter set to > "False"), tags and RAMs are accessed in parallel. Therefore, the hit latency > is the maximum latency between tag lookup latency and RAM access latency. On > the other hand, if the cache access mode is sequential ("sequential_access" > parameter set to "True"), tags and RAM are accessed sequentially. Therefore, > the hit latency is the sum of tag lookup latency plus RAM access latency. > > > Diffs > ----- > > src/mem/cache/tags/fa_lru.hh 80e79ae636ca > src/mem/cache/tags/base.cc 80e79ae636ca > src/mem/cache/tags/Tags.py 80e79ae636ca > src/mem/cache/tags/fa_lru.cc 80e79ae636ca > src/mem/cache/tags/base_set_assoc.hh 80e79ae636ca > src/mem/cache/tags/base.hh 80e79ae636ca > configs/common/Caches.py 80e79ae636ca > src/mem/cache/Cache.py 80e79ae636ca > src/mem/cache/base.hh 80e79ae636ca > src/mem/cache/base.cc 80e79ae636ca > > 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
