Trying to analyze stats like this is often more trouble than it's worth... But anyway, here is one way this could happen I think. Write misses. As long as the in order does not stall for the tlb translations, it can still get memory level parallelism for its writebacks. And if they missed in the L1 the latencies of each write would be quite high. But their latencies would largely not impact performance.
Sent from my phone. On May 9, 2013 4:20 AM, "Chao Zhang" <[email protected]> wrote: > Dear all, > > I'm using gem5 to simulating a cache optimization, but met some trouble. > Help me out, when you found my mistakes. Thanks! > It is configured as alpha inorder CPU with the build_opt given as > "ALPHA_MESI_CMP_directory", and the CPU and caches are set as follows: > > options.cpu_type = 'inorder' > options.caches = 'caches' > options.l1d_size = '64kB' > options.l1i_size = '64kB' > options.l2cache = 'True' > options.l2_size = '1MB' > options.l3cache = 'True' > options.l3_size = '8MB' > > My problem is that when I look at the stats result for benchmark SPEC cpu > 2006 > bzip2, I found the reduction of overall dcache miss latency(15619739000 > ticks) is much larger than that of sim ticks (5569683000 ticks). How > could it be? If the CPU is inorder and the IPC is lease than 1, the > variance of L1 miss latency should roughly smaller than that of CPU time. > Note that optimizations I made did not influence the miss latency > statistics. > > So what's the explanation? > And how can I get the "CPU time contribution Ratio of cache hierarchy" > from the simulator? > > Anybody's response is welcome! > > -- > Chao Zhang > School of EECS, Peking University > > > _______________________________________________ > 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
