Thanks Byn! I thought it did not look correct, but wanted to get some other opinions. Well funnily enough, I am using GEMS actually, and I uncommented the action, since I wanted to look at the number of L2 misses, and this is the only way you can look at it :( I posted the query to GEMS list but I could not get any clarification , and I found the code is same in GEMS and GEM5; hence I posted it here as well.
Thanks for your reply! Abhisek On Tue, Nov 15, 2011 at 1:31 PM, Choi, Byn <[email protected]> wrote: > Abhisek- > > I think this is a bug introduced while moving ruby code from GEMS 2.1.1 > to GEM5. > > On GEMS 2.1.1, uu_profileMiss action in MESI_CMP_directory-L2cache.sm is > actually commented out, so they do not actually register these transitions > as misses (this is pretty misleading). However, the corresponding code in > GEM5 repository ( > http://repo.gem5.org/gem5/file/e66a566f2cfa/src/mem/protocol/MESI_CMP_directory-L2cache.sm#l733), > the action body isn't commented out any more. This code doesn't really > affect the functionality of the code, it just screws up the statistics in > the end, which is much more tricky to catch. > > --- > Byn Choi > Ph.D. Candidate in Computer Science > University of Illinois, Urbana-Champaign > > On Nov 15, 2011, at 11:21 AM, [email protected] wrote: > > Hi, > > I am simulating a CMP (single chip with a shared last level cache) using > the MESI_CMP_directory protocol. I was looking at how the cache misses are > counted > in the MESI_CMP_directory-L2cache.sm files. These are the conditions when > an L2 miss is registered. > > Current State Events > NP GETS, GETX > IS, ISS GETS > SS GETS, GETX, UPGRADE > M GETs, GETX, > MT GETS, GETX > > The relevant state descriptions are as follows: > stable states: > NP, desc="Not present in either cache"; > SS, desc="L2 cache entry Shared, also present in one or more L1s"; > M, desc="L2 cache entry Modified, not present in any L1s"; > MT, desc="L2 cache entry Modified in a local L1, assume L2 copy stale"; > transient states: > ISS, desc="L2 idle, got single L1_GETS, issued memory fetch, have not seen > response yet"; > IS, desc="L2 idle, got L1_GET_INSTR or multiple L1_GETS, issued memory > fetch, have not seen response yet"; > > I am confused why misses are registered for cases when the L2 block is in > M, MT, or SS states. M means the L2 has the value and owns it already, MT > means some L1 cache has > exclusive ownership, which will supply the value. There is no off-chip > access. The only time when there is an off-chip memory access > (a_issueFetchToMemory) is when the L2 is in > NP state. So I thought these are the only cases where we should count an > L2 miss, assuming L2 miss means off-chip access. > > I am struggling to explain all these other cases where L2 miss is > registered. Any ideas / explanation regarding this would be very helpful! > > Thanks a lot! > > -- > Abhisek > Live Long and Prosper > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > > > _______________________________________________ > gem5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
