> On juin 17, 2016, 7:57 matin, 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 > > Radhika Jagtap wrote: > 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?
The distinction between tag and data access also raises the question of the fillLatency value. Does the sequential access mode has to be taken into account on a fill ? In this patch, the fillLatency is assumed to be always equal to data_latency. - Sophiane ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3502/#review8419 ----------------------------------------------------------- On juin 20, 2016, 3:07 après-midi, Sophiane SENNI wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3502/ > ----------------------------------------------------------- > > (Updated juin 20, 2016, 3:07 après-midi) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11536:1a3a96d435ed > --------------------------- > cache: Split the hit latency into tag lookup latency and data access latency > > If the cache access mode is parallel ("sequential_access" parameter set to > "False"), tags and data are accessed in parallel. Therefore, the hit latency > is the maximum latency between tag lookup latency and data access latency. On > the other hand, if the cache access mode is sequential ("sequential_access" > parameter set to "True"), tags and data are accessed sequentially. Therefore, > the hit latency is the sum of tag lookup latency plus data access latency. > > > Diffs > ----- > > 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 > src/mem/cache/tags/fa_lru.hh 80e79ae636ca6b021cbf7aa985b5fd56cb5b2708 > src/mem/cache/tags/fa_lru.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
