Hi Steve, Thanks for your informative response.
I agree that your assumption (why would someone readEx and not write) makes sense, but I think it's a bit limiting. Reasoning: for instance, by default in gem5 data is read as exclusive whenever there are no sharers, with no reason, even when issuing a Read and not ReadEx (please let me know if this isn't the case). Also, the root cause of the symptom I saw was a local change to MEM_INHIBIT's enum in packet.hh without changing COPY_FLAGS and PRIVATE_FLAGS, which caused MEM_INHIBIT not to be copied when the packet was copied along its way to the receiving end. Thanks again, Uri 2012/7/25 Steve Reinhardt <[email protected]> > 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 > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
