> 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
