Hello list members, The current cache coherence protocol in gem5 has a bug (at least in my perspective), which although is a corner case, it is a dangerous one. Currently a we assume a read-exclusive request is responded with clean data. We rely on the ReadEx-issuing master to eventually perform write-back.
The faulty scenario: 1) CPU0 writes to address A. Eventually this will lead to A's block being in M-state in CPU0's cache. 2) CPU1 issues a read-exclusive request to address A. The dirty data is passed from CPU0's cache to CPU1's cache and marked as not-dirty. This is wrong. 3) Upon eviction of this line (e.g. if following reads are to the same set), no writeback will be performed, thus the main memory contains a stale copy. Reason: Currently the MemInhibit reflects ownership-passing but lacks the added information of the data's dirtiness. Meaning, the receiving end (the new owner) assumes the data is clean. Possible solution: Add an indication bit to the response flags, stating whether the data is clean or dirty. This is in addition to the ownership flag (MemInhibit). Possible advantages: A step towards exploring the true impact of ownership-passing and dirty-data passing. For instance, a request can raise the "dirty" bit, signaling it CAN accept dirty data. If not - it is the responsibility of either the responder or the interconnect to perform write-back before passing the data to the requesting master. Your comments are welcome. Thanks Uri _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
