> 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. > > Sophiane SENNI wrote: > 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.
Nikos, For the new patch, I use the "accessLatency" variable, as the latency on every access, in the base class (BaseTags). I tried to initialize this variable in the constructor according to the access mode as follows: BaseTags::BaseTags(const Params *p) : ClockedObject(p), blkSize(p->block_size), size(p->size), lookupLatency(p->tag_latency), dataLatency(p->data_latency), accessLatency(p->sequential_access ? // If sequential access, sum tag lookup and data access latencies (p->tag_latency + p->data_latency) : // If parallel access, take the max latency // between tag lookup and data access (p->tag_latency >= p->data_latency ? p->tag_latency : p->data_latency )), cache(nullptr), warmupBound(0), warmedUp(false), numBlocks(0) { } However, when checking by simulation, the value of "sequential_access" parameter is always taken as "False". Even if this paramater is set to "True" in configs/common/Caches.py Do you have a solution to correctly initialize the "accessLatency" variable in the initialization list ? Thanks. - 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