The L1 will issue a ReadExReq whenever there is a write access that completely misses in the L1. (It's a writeback, write-allocate cache.) The L2 will be able to satisfy the ReadExReq only if it has an exclusive copy of the block. Note that a ReadExReq is a true read; an UpgradeReq is what is issued if the block is in a read-only state in the L1.
Looking more closely at one of our benchmarks (gzip), it appears the vast majority of the ReadExReq misses in the L2 appear to be cold misses, which is why they miss in the L2 as well. It makes sense that you'd be unlikely to have the first access to a block be a write unless the data was uninitialized. There are some UpgradeReqs that still get sent due to a minor issue with how writebacks from the L1 to L2 are handled, but I have a patch for that that I will push soon. There's no way to "turn off" the coherence protocol, it's very tightly tied to the cache implementation in the M5 classic model. Steve 2010/9/15 <zhanglun...@ict.ac.cn>: > Hi Steve, > > I am currently using a uniprocessor version running SPECcpu2006 benchmark. > But I should using multi-program workload in the future work. > > I have tried the latest m5 version you gave me, but I did not see major > differences. For example, when running bzip2 reference workload for > 100000000 insts, the miss rate of the lastest version's ReadExReq is > 98.6931% (not too different from 100% in the m5-stable). I used the > following command to run the benchmark: > > ~/m5_dev/m5-aa8fd8f6a495/build/ALPHA_SE/m5.fast --outdir > ~/m5_dev/m5-aa8fd8f6a495/m5out --stats-file bzip2.txt > ~/m5_dev/m5-aa8fd8f6a495/configs/common/cmp.py -b bzip2 --caches --l2cache > -s -W 1000000000 -I 1100000000 > > I did not managed to fully understand the m5's memory system right now, > and I have a few question about it: > 1> What situation may cause L1 cache to issue ReadExReq to L2 cache? > 2> What is L2 cache's exact behavior to deal with ReadExReq request? > > And, because my current work is just using uniprocessor, is there any way > to bypass coherence protocol in M5? > > Thanks! > > >> Have you tried a recent version of the code? This changeset I pushed >> last week eliminates some (but probably not all) of the unusual >> coherence behavior: >> http://repo.m5sim.org/m5/rev/aa8fd8f6a495 >> >> Also, are you running a uniprocessor or multiprocessor workload? >> >> Steve >> >> >> On Tue, Sep 14, 2010 at 1:59 AM, <zhanglun...@ict.ac.cn> wrote: >>> Hi, >>> >>> I am currently using M5 to simulate LLC's behavior, however I discovery >>> some strange statistics of M5's L2 cache. >>> >>> The problem is like this: I learn that in the stat file, >>> >>> system.l2.demand_accesses = system.l2.ReadExReq_accesses + >>> ??????????????�system.l2.ReadReq_accesses; >>> >>> However, system.l2.ReadExReq_miss_rate is always 100% in all the >>> simulation. This make L2's damand miss rate is always very high, which >>> won't happen in the real system. >>> >>> >>> I checked the source code, and had some of my explanation of this >>> problem: >>> >>> 1> ReadExReq always cause invalidateBlk of the L2 cache, this is why >>> there >>> always is a miss for every ReadExReq access. >>> 2> ReadExReq always derives from the UpgradeReq, which is happen when a >>> L1-cache's block state change from S to E. So actually, ReadExReq is not >>> a >>> really a read request. M5 just uses ReadExReq's side effect to >>> invalidate >>> L2 cache's copy. >>> >>> Thus, I suppose it is safe to ignore ReadExReq. And just focus on >>> ReadReq's statistics for LLC replacement policy study. >>> >>> However, I am not fully understand the M5's memory system. So I am not >>> sure whether my explanation is correct. Can anyone give some comment on >>> the problem and my explanation? Thanks! >>> >>> Best. >>> >>> ?????????????????????????????Lunkai Zhang >>> ???????????????????????�Chinese Academy of >>> Sciences >>> >>> >>> >>> _______________________________________________ >>> m5-users mailing list >>> m5-users@m5sim.org >>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >>> >> _______________________________________________ >> m5-users mailing list >> m5-users@m5sim.org >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >> >> > > > > _______________________________________________ > m5-users mailing list > m5-users@m5sim.org > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users >
_______________________________________________ m5-users mailing list m5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
