Hi Kevin,
On 29/07/2019 03:35, Kevin Smith wrote: > 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 :) > In general, a snooped cache will respond only if * it has a dirty copy of the block, or * it has an outstanding request that will modify the block as soon it completes. > 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. > In your example, neither L1A nor L1B will respond; both will receive a response from L2 - assuming that neither L1A or L1B has the block and both are asking for a read only copy of the block. > 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. > isPendingModified() essentially tells whether the currently outstanding request will modify the block and therefore this cache is the point of ordering for this cache block across this coherence domain. hasSharers() tells if the packet has seen any other caches (by snooping) with a copy of the block or an outstanding request for the same block. cacheResponding() tells if any other cache (previously snooped) has committed to responding; this implies that the cache had a dirty copy of the block or a pendingModified() MSHR. > 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. > IIRC, in your example system, the L2 won't ever set the cacheResponding flag. If you had more caches below the L2, the L2 would set it, if it needed to send an express snoop to the cache below; this can happen if there is request that requires a writable copy of the block, L2 has a dirty copy of the block, so it will respond, but at the same time, it will send a request to invalidate other copies of the block in caches below. > 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. > The cacheResponding flag can be set only once for a given packet - set by the cache with a dirty copy of the block at that particular level, if there is more than one we have a bug and that's why we have assertions about it. hasSharers is a much more forgiving flag, it tells the requester whether the copy it got is exclusive and at the same time, allows to assert assumptions. This can get quite complex, but if you have a particular example in mind, I'm happy to help with that. Cheers, Nikos > 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 > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
