> 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