Hi Uri, The basic idea is that, if CPU1 issues a read-exclusive request, then it is assumed that CPU1 wanted to do a write, so CPU1 will be setting the dirty bit anyway. There is a corner case around conditional writes (like LLSC or CAS) where CPU1 might change its mind about writing after it receives the data, but this patch is supposed to cover that case too: http://repo.gem5.org/gem5/rev/8d92c2737ac8
Is there some other situation where a CPU is issuing a read-exclusive request but not performing a write or otherwise setting the dirty bit? Steve On Wed, Jul 25, 2012 at 6:52 AM, Uri Wiener <[email protected]> wrote: > 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 > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
