If core 0's exclusive request reaches the L1-L2 bus before core 1's, then core 0 should suppress the cache response to core 1 and deliver the block directly via a cache-to-cache transfer after it receives (and writes to) its exclusive copy. The L2 would not end up with two MSHR targets, just the one for core 0.
Steve On Sat, May 17, 2014 at 1:40 AM, biswabandan panda via gem5-users < gem5-users@gem5.org> wrote: > Hi, > If I have this scenario, > 2 cores, 2 levels of cache > L1(private), L2(shared) > Both the cores have generated a miss for address X. > Core 0 - a read exclusive miss (its a write request) > Core 1 - a read miss > Now L2 MSHR has two targets for address X. > When the first target is popped out, in satisfyCpuSideRequest, the block > is invalidated at L2 and the response sent to Core 0. > For the second target the assert should have failed (in > satisfyCpuSideRequest) > assert(blk && blk->isValid()); > But I have never come across this assert failing even for 64 cores running > PARSEC benchamarks. > How is gem5 handling this particular scenario? > If the address X was dirty in L2, how is gem5 responding back? > I am a bit confused. Any light on this will be of great help. Thank you > for your time. > > -- > > > *thanks®ards* > *BISWABANDAN* > http://www.cse.iitm.ac.in/~biswa/ > > “We might fall down, but we will never lay down. We might not be the best, > but we will beat the best! We might not be at the top, but we will rise.” > > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
