Part of it might be from instructions that fault like loads that miss
in the TLB. Those might count towards instructions the commit stage
committed (since they finished) but not towards the count the CPU is
tracking because they didn't commit without a fault. I haven't
verified that this is actually what's happening. If it is, the
difference is a little confusing, but might be there to keep EIO
traces happy. Those expect particular numbers of instructions counted
in a particular way to have occurred between important events like
system calls.
Gabe
Quoting Dawei Wang <[email protected]>:
Hello, everyone,
Now I am using M5 to simulation Spec CPU2006, I have got some in-consistence
statistics, Hope someone could give reasonable explanations.
I simulated benchmark 401.bzip2 with 1 billion instructions, and only one
cpu core in SE mode.
The simulations cmd is here:
build/ALPHA_SE/m5.opt /configs/example/se_cpu2006.py -n1 --detailed --caches
--l2cache --maxinsts 1000000000 -b bzip2
[1] The first question is there are two commit parameters showing below.
According to their names, I guess they are both meaning how many are
instruction are committed. But there number are different, any reason? I
want to simulated 1,000,000,000 insts.
system.cpu.commit.COM:count 1001844707 # Number of instructions
committed
system.cpu.committedInsts 1000000000 # Number of Instructions
Simulated
system.cpu.committedInsts_total 1000000000 # Number of Instructions
Simulated
Simply, my question is why "system.cpu.commit.COM:count
!= system.cpu.committedInsts"? what is the difference come from?
[2]The second question is why the # of memory loads inst committed is not
equal to L1 dcache ReadReq demand access?
why the # of memory reference inst committed is not equal to L1 dcache
overall demand access?
system.cpu.commit.COM:loads 235487280 # Number of loads committed
system.cpu.commit.COM:membars 70 # Number of memory barriers
committed
system.cpu.commit.COM:refs 328322098 # Number of memory
references committed
system.cpu.dcache.ReadReq_accesses 279749292 # number of ReadReq
accesses(hits+misses)
system.cpu.dcache.WriteReq_accesses 92768715 # number of WriteReq
accesses(hits+misses)
Simply, my question is why "system.cpu.commit.COM:loads
!=system.cpu.dcache.ReadReq_accesses"? where the extra dcache ReadReq come
from? One of my guess is the difference is from some speculation
instructions, there load instructions finally does not commit, but I am not
sure whether all two number difference is coming from un-committed load
instruction?
[3]The third question is how do we define idleCycles? Is that mean there is
no operation in any functional unit due to data dependency or waiting
loading data from memory?
system.cpu.idleCycles 7409255 # Total number of cycles that the CPU has
spent unscheduled due to idling
Many thanks in advance
Dawei
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
