Hi Steve, The bug was local, so no action needed. I fixed my patch so whatever will be committed won't break anything (touch wood). I questioned the reading-as-exclusive-by-default since this is an optimization - assumes this'll save upgrade requests, and that downgrading E->S on snoop hit is negligible. So anything not strictly by-the-book is a potential bug :-)
Thanks again, Uri 2012/7/25 Steve Reinhardt <[email protected]> > 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 > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
