Thanks Steve and Nate! It's getting clearer to me now. Best, Jie
On Apr 28, 2010, at 8:24 PM, Steve Reinhardt wrote: > As far as the stats, the best way to understand what's counted is to > look at the code in src/mem/cache/cache_impl.hh, especially the > access() method. > > On Wed, Apr 28, 2010 at 2:46 PM, Jie Meng <[email protected]> wrote: >> 1) In our simulations, "system.l2.Writeback_accesses" is always = >> "system.l2.Writeback_hits". But the trace shows there're L2 Writeback >> misses. Why there's no L2 Writeback misses in stats.txt? > > There's a comment in access() that explains this... basically even if > a writeback isn't a hit it's not really handled like a miss either. > >> >> 2) In stats.txt, there is another parameter called "system.l2.writebacks", >> how is it related to the "system.l2.Writeback_accesses"? > > The former counts writebacks generated by the cache, while the latter > is writeback requests received by the cache. > >> >> 3) I noticed that, "system.l2.overall_accesses" is always = >> "system.l2.ReadExReq_accesses" + "system.l2.ReadReq_accesses::total", and >> "system.l2.ReadExReq_accesses" always = "system.l2.ReadExReq_misses", why is >> that? If ReadReq_accesses are always missed, why bother to have two >> parameters? > > If ReadExReq accesses always miss in the L2, that's at best an > unintended consequence of how exclusive data is handled in the > hierarchy and at worst a bug of some sort. I thought we tracked > whether a writeback was an exclusive copy or not, so that we could > install it in a writeable state in the L2, but I don't see that code > now. > >> >> 4) The memory trace for my simulations are very large (around 10GB for a >> simulation). I commented most DPRINTF functions and only leave hits and >> misses, but it is still too large for me. Does anybody have this problem >> before? And is there a way in M5 to sample the trace by setting a time >> interval? > > DPRINTF is really just for debugging (that's what the "D" stands for). > If you are trying to generate an address trace (e.g., to use later in > a trace-based simulation) you should add your own code to output > requests in a binary format. If you're debugging but you think you > need a trace that large, you may want to find a different debugging > technique that doesn't require storing the trace on disk. > > Steve > _______________________________________________ > 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
