Hi all, I have a question regarding the classic memory model, about how a cache knows when to respond to a peer (neighbor) cache. Please bear with me as I try to diagnose what happens and let me know where/if I'm wrong :)
Assume a simple system with two L1s and one L2, and some line (AKA CacheBlk in gem5 parlance) exists only in the L2. Assume L1A sends out a read request r1 for that line, and creates an MSHR for it. Then L1B sends out a read request r2 for it as well. L1A would snoop that request and needs to decide whether to respond to r2 after it has r1 satisfied, based on what coherent state it expects to get the line back in. It appears in gem5 this decision happens in MSHR::handleSnoop(). Part of the logic is setting will_respond based on isPendingModified(). And isPendingModified() is based on whether, when L1A sent the packet, hasSharers() and cacheResponding() was asserted on the packet. As far as I can tell, hasSharers() and cacheResponding() may be set both by peer L1s *and* by the L2. E.g. it looks like the L2 can call pkt->setHasSharers() and/or pkt->setCacheResponding() inside Cache::satisfyRequest(), which I believe is the "L2 responds to L1" path. So, my question is: why is the L2 able to set these flags right when it receives the request? It seems like the L1 makes decisions based on these flags before the L2 would feasibly be able to know about what to set these flags to in a real system -- i.e. the L2 would need to wait for at least its own hit latency before it would know how to respond, and yet the L1 immediately makes decisions based off of this. Any explanation about what's happening here would be highly appreciated! Kevin
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
