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
