Hi Steve, Thanks for your clarification.
Correct me if I'm wrong: In SE mode, since there won't be any data sharing/communication among different cores, a L1 read miss can safely set the fetched block (as well as filled in block in lower cache levels) as Exclusive state in MOESI (valid, writable, !dirty), as opposite to what M5 does now (all set to Shared - valid, !writable, !dirty). For the same reason, the L1 write miss does not have to invalidate the block in L2.
Thanks. Weixun On 10/22/2010 6:17 PM, Steve Reinhardt wrote:
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
-- 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
