I've posted a preliminary patch at http://reviews.gem5.org/r/1872/. Any
feedback is much appreciated.
-Erik
On 15/05/13 12:24, Erik Tomusk wrote:
I think what I was trying to say is that a cachePorts limit and
blocking due to MSHR are independent, and MSHR blocking already
exists. I.e.
IF (cachePorts available) AND (cache not blocked) AND (cache miss)
THEN (still counts as using up a cache port)
Alternatively
IF (cachePorts available) AND (cache blocked)
THEN (shouldn't count as using up a cache port but practically doesn't
matter because no other requests can go through in that cycle anyway)
Finally
IF (no cachePorts left this cycle)
THEN (don't bother sending request to cache; it doesn't matter if
cache is blocked or not)
-Erik
On 14/05/13 22:37, Korey Sewell wrote:
Erik,
Can you explain this line further about MSHRs:
If I understand correctly, a cache miss is still physically a
cache access, so what happens in the MSHR shouldn't affect how
many requests the core sends per cycle.
If your MSHRs are full, then the cache should send a blocking signal
back to the CPU saying that it can not accept any more accesses, no?
Otherwise, how are you planning to fill the potential miss?
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
_______________________________________________
gem5-users mailing list
gem5-users@gem5.org
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
