Different cache latency for read and write access

Information
Submitter:	Sophiane SENNI
Repository:	gem5
Branch:
Bugs:
Depends On:
Reviewers
Groups:	Default
People:

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)

Testing Done

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.

Status: Discarded

Status: Re-opened

Summary:

+	Different cache latency for read and write access

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)

Testing Done:

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.

Diff:

Revision 2 (+21 -5)

Show changes

	src/mem/cache/BaseCache.py
	src/mem/cache/base.hh
	src/mem/cache/base.cc
	src/mem/cache/cache_impl.hh
	src/mem/cache/tags/lru.hh
	src/mem/cache/tags/lru.cc

Change Summary:

A mistake made in LRU::accessBlock function. The "lat" parameter has to be passed by reference (not by value). Sorry...

Diff:

Revision 3 (+19 -3)

Show changes

	src/mem/cache/BaseCache.py
	src/mem/cache/base.hh
	src/mem/cache/base.cc
	src/mem/cache/cache_impl.hh
	src/mem/cache/tags/lru.cc

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 Nov. 16, 2013, 1:49 a.m. (Nov. 16, 2013, 1:49 a.m.)

Thank you very much for your post. I will try to complete this patch and post an update.

Sophiane SENNI Nov. 20, 2013, 2:22 a.m. (Nov. 20, 2013, 2:22 a.m.)

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

Ali Saidi Dec. 27, 2013, 10:20 a.m. (Dec. 27, 2013, 10:20 a.m.)

I'm pretty sure response_latency is the latency up to the requestor when a fill happens, but isn't the latency for a cache-to-cache transfer.

Change Summary:

Consider the cache write latency for writes coming from memory side (cache fill)

Diff:

Revision 4 (+21 -5)

Show changes

	src/mem/cache/BaseCache.py
	src/mem/cache/base.hh
	src/mem/cache/base.cc
	src/mem/cache/cache_impl.hh
	src/mem/cache/tags/lru.cc

How can we get this into shape, and how does it align with: http://reviews.gem5.org/r/1822/?

Also, if all we do is add latency, how does it affect the throughput (are we assuming pipelining or not)?

You have a pending review.

Review Board 2.0.15

This change has been discarded.

Screenshots

Files

Status: Discarded

Status: Discarded

Status: Discarded

Status: Re-opened

Summary:

Description:

Testing Done:

Diff:

Change Summary:

Diff:

Change Summary:

Diff:

Status: Discarded