Sorry for the slow reply... the key thing to remember about the built-in m5 coherence protocol is that one of the primary features is that it works for arbitrary bus-based hierarchies. There are some things that it does that are sub-optimal for specific hierarchies (and for uniprocessors in particular) that stem from this need to work in arbitrary configurations. For example, the L2 in your case doesn't know that it's the only L2 in the system, so it has to let the write miss go through in case there are other L2s that need to snoop it.
That said, I have put some fixes in lately (just a month ago, see for example http://repo.m5sim.org/m5/rev/d1ba390671ec) that get rid of some of the more egregious issues. Which version of the code were you looking at? You may want to try again with the latest code if it wasn't recent. There's some (dated) background here that may be useful: http://m5sim.org/wiki/index.php/Coherence_Protocol Steve On Fri, Oct 22, 2010 at 9:17 AM, Weixun Wang <[email protected]> wrote: > Any help? > > thanks... > > On 10/16/2010 12:58 AM, Weixun Wang wrote: > > Hi All, > > I found the following fact by tracing the simulation: > > I-L1 miss: L2 hit: get back to L1 [Seems normal...] > L2 miss: fetch from memory, get back to L1 [Seems > normal...] > > D-L1 read miss: L2 hit: get back to L1 [Seems normal...] > L2 miss: fetch from memory, get back to L1 > [Seems normal...] > D-L1 write miss: L2 hit: ALWAYS "Not Writable", forced to become a miss, > fetch from memory, then invalidate L2 block > L2 miss: fetch from mem, then invalidate L2 > block > D-L1 writeback: L2 hit: > L2 miss: block either in L2 but NOT valid (most > common) or not in L2 > > ---------------------------------------------------------------------------------------- > > 1. My confusion is that, why it is designed in the way such that whenever > there is a D-L1 cache write miss to L2, even if the corresponding block is > in L2 and is valid, it is always not writable which forces a L2 miss to > fetch from memory. (I suspect the block is set to not writable in > Cache<TagStore>::satisfyCpuSideRequest when pkt->isRead() and > !pkt->needsExclusive()). Even the initial read is from the same CPU (or even > when there is only one CPU), the L2 block is made un-writable. > > 2. Another observation is that, whenever there is a writeback from D-L1 > cache, it is always a L2 miss (block is in L2 but not valid). I found that > if D-L1 write hits in D-L1 (L1 hit), the corresponding L2 block is untouched > (not invalidate). Then why it becomes invalid when writeback happens??? > > Is my understanding correct? > > Thanks. > > -- > Best Regards, > > Wang, Weixun > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > -- > Best Regards, > > Wang, Weixun > > Department of Computer & Information Science & Engineering > Gator College of Engineering > University of Florida > Gainesville, FL 32611 > http://www.cise.ufl.edu/~wewang > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
