On Wed, Jul 25, 2012 at 1:00 PM, Uri Wiener <[email protected]> wrote:
> 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). > It's true that by default a reader will get an exclusive copy without asking for one when there are no sharers (the whole point of the E state), but the optimization of handing off ownership in a cache-to-cache transfer only occurs when the requester has explicitly asked for an exclusive copy (pretty much for the very reason we are discussing). > 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 for tracking this down. Does this bug still exist in the tip? If so, could you post a patch to reviews.gem5.org? Thanks! Steve > > 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 > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
