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
