> On Nov. 13, 2013, 2:24 p.m., Mihai Lefter wrote:
> > Currently I was also looking into this issue (adding an extra write latency 
> > actually). As far as I can see this patch considers a different write 
> > latency only for write operations that come from the CPU side, i.e., on the 
> > cpuSidePort of the cache. For the patch to be complete, it should consider 
> > also a different cache write latency when writes come from the memory side, 
> > i.e., on the memSidePort of the cache.
> > 
> > Some changes in the following functions may be required (in 
> > src/mem/cache/cache_impl.hh):
> > 
> > 00858 Cache<TagStore>::recvTimingResp(PacketPtr pkt)
> > .....
> > 00939                 // If critical word (no offset) return first word 
> > time.
> > 00940                 // responseLatency is the latency of the return path
> > 00941                 // from lower level caches/memory to an upper level 
> > cache or
> > 00942                 // the core.
> > 00943                 completion_time = clockEdge(responseLatency) +
> > 00944                     (transfer_offset ? pkt->busLastWordDelay :
> > 00945                      pkt->busFirstWordDelay);
> > .....
> > 01211 Cache<TagStore>::handleFill(PacketPtr pkt, BlkType *blk,
> > 01212                             PacketList &writebacks)
> > .....
> > 01270     blk->whenReady = clockEdge() + responseLatency * clockPeriod() +
> > 01271         pkt->busLastWordDelay;
> > 
> > Apparently, in the recvTimingResp() function it seems that completion_time 
> > is only used for stats, while in handlefill() the actual write (a cache 
> > fill from the memory side) in the cache takes place. Note that the fill 
> > takes multiple bus cycles, thus, the write latency should take this into 
> > account. 
> > 
> > As a last thing, maybe a new parameter should be added, i.e., 
> > writeResponseLatency.
> >
> 
> Sophiane SENNI wrote:
>     Thank you very much for your post. I will try to complete this patch and 
> post an update.

I am wondering if the latency for write operations coming from memSidePort 
(like cache fill) is not actually the response_latency ? Or the 
response_latency is something different ?

Ali, Andreas, could you confirm if response_latency is the cache fill latency 
or not ?

Thanks


- Sophiane


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2072/#review4805
-----------------------------------------------------------


On Nov. 4, 2013, 9:44 a.m., Sophiane SENNI wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2072/
> -----------------------------------------------------------
> 
> (Updated Nov. 4, 2013, 9:44 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> -------
> 
> This patch allows specifying different cache latency for read and write 
> access. (In the code, the hit_latency parameter is actually the read_latency)
> 
> 
> Diffs
> -----
> 
>   src/mem/cache/BaseCache.py 07352f119e48 
>   src/mem/cache/base.hh 07352f119e48 
>   src/mem/cache/base.cc 07352f119e48 
>   src/mem/cache/cache_impl.hh 07352f119e48 
>   src/mem/cache/tags/lru.cc 07352f119e48 
> 
> Diff: http://reviews.gem5.org/r/2072/diff/
> 
> 
> Testing
> -------
> 
> I used --debug-flags command to check read hit latency and write hit latency 
> for Dcache and Icache. I checked the time between a request sent by the cpu 
> and the response sent by the cache memory.
> 
> 
> Thanks,
> 
> Sophiane SENNI
> 
>

_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to