Fellow gem5 developers, I have just posted a number of patches on the reviewboard that address two issues with the memory model of the classic memory system. This is a short description of the context for these patches to help out with any reviews.
The first set of patches deals with memory ordering issues when two consecutive read requests miss in the cache and the downstream cache receives an invalidating snoop request in between. Currently the cache would service both read requests with the same response despite the fact that the ordering point (the downstream cache) received an invalidating snoop between the two requests. The following patches address this issue by deferring the second read request when a read response with invalidate is received. The issue can be reproduced using the memchecker after #3727 has been applied. 1) #3724 - mem: Add support for repopulating the flags of an MSHR TargetList 2) #3725 - mem: Keep track of allocOnFill in the TargetList 3) #3726 - mem: Service only the 1st FromCPU MSHR target on ReadRespWithInv 4) #3727 - cpu: Change traffic generators to use different values for writes The second set of patches deals with memory ordering issues in the presence of whole line writes. In the classic memory system, whole line requests that miss send out invalidations requests to every cache down to the point of coherency. The point of coherency (xbar) always responds to the invalidation request after it has sent snoops to all upstream caches. This creates problems as there is no ordering point and write line requests get serviced in an arbitrary order. This series of patches makes the cache with the (pending) dirty copy, or otherwise the point of coherency (xbar) the ordering point which responds the to the invalidation request. This way invalidation requests are handled in the same way as upgrade requests. The whole line memory order issue can be reproduced by the memchecker after #3726 has been applied. 1) #3728 - mem: Make packet debug printing more uniform 2) #3729 - mem: Ensure InvalidateReq is considered isForward by MSHRs 3) #3730 - mem: Assert that the responderHadWritable is set only once 4) #3731 - mem: Always use InvalidateReq to service WriteLineReq misses 5) #3732 - mem: Don't use hasSharers in the snoopFilter for memory responses 6) #3733 - mem: Allow non invalidating snoops on an InvalidateReq MSHR 7) #3734 - mem: Invalidate a blk when servicing the 1st invalidating target 8) #3735 - mem: Respond to InvalidateReq when the block is (pending) dirty 9) #3736 - config: Add whole line accesses to improve memchecker's coverage) 10) #3737 - config: Add an option to generate a random topology in memcheck Thanks, Nikos 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-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
