Hey Erik, I think I see what you were saying here. Thanks for the comments and effort on this so far.
-Korey On Wed, May 15, 2013 at 4:24 AM, Erik Tomusk <e.tom...@sms.ed.ac.uk> 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 > listgem5-users@gem5.orghttp://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 > -- - Korey
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
