sanchayanmaity/gem5
1
0
Fork 0
Code Issues Pull requests Packages Projects Releases Wiki Activity
gem5/tests/quick/se/00.hello/ref/mips/linux/o3-timing/stats.txt

582 lines
66 KiB
Plaintext
Raw Normal View History

o3-mips-regress: add hello word regression.
2009-04-18 16:42:29 +02:00
---------- Begin Simulation Statistics ----------
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
sim_seconds 0.000012 # Number of seconds simulated
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
sim_ticks 12272500 # Number of ticks simulated
stats: Update stats for final tick and memory bandwidth patches
2012-01-25 18:19:50 +01:00
final_tick 12272500 # Number of ticks from beginning of simulation (restored from checkpoints and never reset)
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
sim_freq 1000000000000 # Frequency of simulated ticks
stats: update stats for insts/ops and master id changes
2012-02-12 23:07:43 +01:00
host_inst_rate 97350 # Simulator instruction rate (inst/s)
host_op_rate 97317 # Simulator op (including micro ops) rate (op/s)
host_tick_rate 230983195 # Simulator tick rate (ticks/s)
host_mem_usage 211060 # Number of bytes of host memory used
host_seconds 0.05 # Real time elapsed on the host
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
sim_insts 5169 # Number of instructions simulated
stats: update stats for insts/ops and master id changes
2012-02-12 23:07:43 +01:00
sim_ops 5169 # Number of ops (including micro ops) simulated
stats: Update stats for final tick and memory bandwidth patches
2012-01-25 18:19:50 +01:00
system.physmem.bytes_read 30400 # Number of bytes read from this memory
system.physmem.bytes_inst_read 21312 # Number of instructions bytes read from this memory
system.physmem.bytes_written 0 # Number of bytes written to this memory
system.physmem.num_reads 475 # Number of read requests responded to by this memory
system.physmem.num_writes 0 # Number of write requests responded to by this memory
system.physmem.num_other 0 # Number of other requests responded to by this memory
system.physmem.bw_read 2477082909 # Total read bandwidth from this memory (bytes/s)
system.physmem.bw_inst_read 1736565492 # Instruction read bandwidth from this memory (bytes/s)
system.physmem.bw_total 2477082909 # Total bandwidth to/from this memory (bytes/s)
o3-mips-regress: add hello word regression.
2009-04-18 16:42:29 +02:00
system.cpu.dtb.read_hits 0 # DTB read hits
system.cpu.dtb.read_misses 0 # DTB read misses
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.dtb.read_accesses 0 # DTB read accesses
o3-mips-regress: add hello word regression.
2009-04-18 16:42:29 +02:00
system.cpu.dtb.write_hits 0 # DTB write hits
system.cpu.dtb.write_misses 0 # DTB write misses
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.dtb.write_accesses 0 # DTB write accesses
system.cpu.dtb.hits 0 # DTB hits
system.cpu.dtb.misses 0 # DTB misses
system.cpu.dtb.accesses 0 # DTB accesses
system.cpu.itb.read_hits 0 # DTB read hits
system.cpu.itb.read_misses 0 # DTB read misses
system.cpu.itb.read_accesses 0 # DTB read accesses
system.cpu.itb.write_hits 0 # DTB write hits
system.cpu.itb.write_misses 0 # DTB write misses
system.cpu.itb.write_accesses 0 # DTB write accesses
system.cpu.itb.hits 0 # DTB hits
system.cpu.itb.misses 0 # DTB misses
system.cpu.itb.accesses 0 # DTB accesses
system.cpu.workload.num_syscalls 8 # Number of system calls
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.numCycles 24546 # number of cpu cycles simulated
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.numWorkItemsStarted 0 # number of work items this cpu started
system.cpu.numWorkItemsCompleted 0 # number of work items this cpu completed
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.BPredUnit.lookups 1975 # Number of BP lookups
system.cpu.BPredUnit.condPredicted 1343 # Number of conditional branches predicted
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.BPredUnit.condIncorrect 399 # Number of conditional branches incorrect
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.BPredUnit.BTBLookups 1578 # Number of BTB lookups
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.BPredUnit.BTBHits 493 # Number of BTB hits
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.BPredUnit.BTBCorrect 0 # Number of correct BTB predictions (this stat may not work properly.
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.BPredUnit.usedRAS 251 # Number of times the RAS was used to get a target.
system.cpu.BPredUnit.RASInCorrect 71 # Number of incorrect RAS predictions.
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.fetch.icacheStallCycles 7903 # Number of cycles fetch is stalled on an Icache miss
system.cpu.fetch.Insts 12258 # Number of instructions fetch has processed
system.cpu.fetch.Branches 1975 # Number of branches that fetch encountered
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.fetch.predictedBranches 744 # Number of branches that fetch has predicted taken
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.fetch.Cycles 3024 # Number of cycles fetch has run and was not squashing or blocked
system.cpu.fetch.SquashCycles 1186 # Number of cycles fetch has spent squashing
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.fetch.BlockedCycles 756 # Number of cycles fetch has spent blocked
system.cpu.fetch.MiscStallCycles 1 # Number of cycles fetch has spent waiting on interrupts, or bad addresses, or out of MSHRs
system.cpu.fetch.PendingTrapStallCycles 145 # Number of stall cycles due to pending traps
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.fetch.CacheLines 1781 # Number of cache lines fetched
system.cpu.fetch.IcacheSquashes 229 # Number of outstanding Icache misses that were squashed
system.cpu.fetch.rateDist::samples 12608 # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::mean 0.972240 # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::stdev 2.277843 # Number of instructions fetched each cycle (Total)
tests: stats outputs now include CDFs, update tests that use those so they're easier to diff
2009-07-07 00:49:48 +02:00
system.cpu.fetch.rateDist::underflows 0 0.00% 0.00% # Number of instructions fetched each cycle (Total)
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.fetch.rateDist::0 9584 76.02% 76.02% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::1 1250 9.91% 85.93% # Number of instructions fetched each cycle (Total)
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.fetch.rateDist::2 108 0.86% 86.79% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::3 139 1.10% 87.89% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::4 289 2.29% 90.18% # Number of instructions fetched each cycle (Total)
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.fetch.rateDist::5 92 0.73% 90.91% # Number of instructions fetched each cycle (Total)
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.fetch.rateDist::6 132 1.05% 91.96% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::7 145 1.15% 93.11% # Number of instructions fetched each cycle (Total)
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.fetch.rateDist::8 869 6.89% 100.00% # Number of instructions fetched each cycle (Total)
tests: stats outputs now include CDFs, update tests that use those so they're easier to diff
2009-07-07 00:49:48 +02:00
system.cpu.fetch.rateDist::overflows 0 0.00% 100.00% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::min_value 0 # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::max_value 8 # Number of instructions fetched each cycle (Total)
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.fetch.rateDist::total 12608 # Number of instructions fetched each cycle (Total)
system.cpu.fetch.branchRate 0.080461 # Number of branch fetches per cycle
system.cpu.fetch.rate 0.499389 # Number of inst fetches per cycle
system.cpu.decode.IdleCycles 8092 # Number of cycles decode is idle
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.decode.BlockedCycles 871 # Number of cycles decode is blocked
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.decode.RunCycles 2857 # Number of cycles decode is running
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.decode.UnblockCycles 51 # Number of cycles decode is unblocking
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.decode.SquashCycles 737 # Number of cycles decode is squashing
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.decode.BranchResolved 107 # Number of times decode resolved a branch
system.cpu.decode.BranchMispred 43 # Number of times decode detected a branch misprediction
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.decode.DecodedInsts 11425 # Number of instructions handled by decode
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.decode.SquashedInsts 162 # Number of squashed instructions handled by decode
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.rename.SquashCycles 737 # Number of cycles rename is squashing
system.cpu.rename.IdleCycles 8263 # Number of cycles rename is idle
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.rename.BlockCycles 258 # Number of cycles rename is blocking
system.cpu.rename.serializeStallCycles 499 # count of cycles rename stalled for serializing inst
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.rename.RunCycles 2740 # Number of cycles rename is running
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.rename.UnblockCycles 111 # Number of cycles rename is unblocking
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.rename.RenamedInsts 11004 # Number of instructions processed by rename
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.rename.LSQFullEvents 101 # Number of times rename has blocked due to LSQ full
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.rename.RenamedOperands 6697 # Number of destination operands rename has renamed
MIPS: Fix regressions tests
2011-09-17 18:34:03 +02:00
system.cpu.rename.RenameLookups 13109 # Number of register rename lookups that rename has made
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.rename.int_rename_lookups 13105 # Number of integer rename lookups
MIPS: Fix regressions tests
2011-09-17 18:34:03 +02:00
system.cpu.rename.fp_rename_lookups 4 # Number of floating rename lookups
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.rename.CommittedMaps 3410 # Number of HB maps that are committed
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.rename.UndoneMaps 3287 # Number of HB maps that are undone due to squashing
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.rename.serializingInsts 18 # count of serializing insts renamed
system.cpu.rename.tempSerializingInsts 11 # count of temporary serializing insts renamed
system.cpu.rename.skidInsts 281 # count of insts added to the skid buffer
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.memDep0.insertedLoads 2346 # Number of loads inserted to the mem dependence unit.
system.cpu.memDep0.insertedStores 1174 # Number of stores inserted to the mem dependence unit.
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.memDep0.conflictingLoads 1 # Number of conflicting loads.
system.cpu.memDep0.conflictingStores 1 # Number of conflicting stores.
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iq.iqInstsAdded 8640 # Number of instructions added to the IQ (excludes non-spec)
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iq.iqNonSpecInstsAdded 13 # Number of non-speculative instructions added to the IQ
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iq.iqInstsIssued 7815 # Number of instructions issued
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.iq.iqSquashedInstsIssued 50 # Number of squashed instructions issued
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iq.iqSquashedInstsExamined 2984 # Number of squashed instructions iterated over during squash; mainly for profiling
system.cpu.iq.iqSquashedOperandsExamined 1806 # Number of squashed operands that are examined and possibly removed from graph
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iq.iqSquashedNonSpecRemoved 3 # Number of squashed non-spec instructions that were removed
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iq.issued_per_cycle::samples 12608 # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::mean 0.619845 # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::stdev 1.285923 # Number of insts issued each cycle
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.iq.issued_per_cycle::underflows 0 0.00% 0.00% # Number of insts issued each cycle
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iq.issued_per_cycle::0 9257 73.42% 73.42% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::1 1317 10.45% 83.87% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::2 832 6.60% 90.47% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::3 510 4.05% 94.51% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::4 356 2.82% 97.34% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::5 201 1.59% 98.93% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::6 85 0.67% 99.60% # Number of insts issued each cycle
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.iq.issued_per_cycle::7 35 0.28% 99.88% # Number of insts issued each cycle
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iq.issued_per_cycle::8 15 0.12% 100.00% # Number of insts issued each cycle
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.iq.issued_per_cycle::overflows 0 0.00% 100.00% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::min_value 0 # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::max_value 8 # Number of insts issued each cycle
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iq.issued_per_cycle::total 12608 # Number of insts issued each cycle
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.iq.fu_full::No_OpClass 0 0.00% 0.00% # attempts to use FU when none available
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.iq.fu_full::IntAlu 3 2.05% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::IntMult 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::IntDiv 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatAdd 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatCmp 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatCvt 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatMult 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatDiv 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatSqrt 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdAdd 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdAddAcc 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdAlu 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdCmp 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdCvt 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdMisc 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdMult 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdMultAcc 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdShift 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdShiftAcc 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdSqrt 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatAdd 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatAlu 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatCmp 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatCvt 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatDiv 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatMisc 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatMult 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatMultAcc 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatSqrt 0 0.00% 2.05% # attempts to use FU when none available
system.cpu.iq.fu_full::MemRead 91 62.33% 64.38% # attempts to use FU when none available
system.cpu.iq.fu_full::MemWrite 52 35.62% 100.00% # attempts to use FU when none available
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.iq.fu_full::IprAccess 0 0.00% 100.00% # attempts to use FU when none available
system.cpu.iq.fu_full::InstPrefetch 0 0.00% 100.00% # attempts to use FU when none available
tests: update stats for name changes
2011-04-20 03:45:23 +02:00
system.cpu.iq.FU_type_0::No_OpClass 0 0.00% 0.00% # Type of FU issued
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iq.FU_type_0::IntAlu 4596 58.81% 58.81% # Type of FU issued
system.cpu.iq.FU_type_0::IntMult 4 0.05% 58.86% # Type of FU issued
system.cpu.iq.FU_type_0::IntDiv 2 0.03% 58.89% # Type of FU issued
system.cpu.iq.FU_type_0::FloatAdd 2 0.03% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::FloatCmp 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::FloatCvt 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::FloatMult 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::FloatDiv 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::FloatSqrt 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdAdd 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdAddAcc 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdAlu 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdCmp 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdCvt 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdMisc 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdMult 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdMultAcc 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdShift 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdShiftAcc 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdSqrt 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatAdd 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatAlu 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatCmp 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatCvt 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatDiv 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatMisc 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatMult 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatMultAcc 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatSqrt 0 0.00% 58.91% # Type of FU issued
system.cpu.iq.FU_type_0::MemRead 2128 27.23% 86.14% # Type of FU issued
system.cpu.iq.FU_type_0::MemWrite 1083 13.86% 100.00% # Type of FU issued
tests: update stats for name changes
2011-04-20 03:45:23 +02:00
system.cpu.iq.FU_type_0::IprAccess 0 0.00% 100.00% # Type of FU issued
system.cpu.iq.FU_type_0::InstPrefetch 0 0.00% 100.00% # Type of FU issued
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iq.FU_type_0::total 7815 # Type of FU issued
system.cpu.iq.rate 0.318382 # Inst issue rate
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.iq.fu_busy_cnt 146 # FU busy when requested
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iq.fu_busy_rate 0.018682 # FU busy rate (busy events/executed inst)
system.cpu.iq.int_inst_queue_reads 28430 # Number of integer instruction queue reads
system.cpu.iq.int_inst_queue_writes 11643 # Number of integer instruction queue writes
system.cpu.iq.int_inst_queue_wakeup_accesses 7116 # Number of integer instruction queue wakeup accesses
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.iq.fp_inst_queue_reads 4 # Number of floating instruction queue reads
system.cpu.iq.fp_inst_queue_writes 2 # Number of floating instruction queue writes
system.cpu.iq.fp_inst_queue_wakeup_accesses 2 # Number of floating instruction queue wakeup accesses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iq.int_alu_accesses 7959 # Number of integer alu accesses
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.iq.fp_alu_accesses 2 # Number of floating point alu accesses
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iew.lsq.thread0.forwLoads 65 # Number of loads that had data forwarded from stores
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.iew.lsq.thread0.invAddrLoads 0 # Number of loads ignored due to an invalid address
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.lsq.thread0.squashedLoads 1182 # Number of loads squashed
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iew.lsq.thread0.ignoredResponses 4 # Number of memory responses ignored because the instruction is squashed
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.lsq.thread0.memOrderViolation 8 # Number of memory ordering violations
system.cpu.iew.lsq.thread0.squashedStores 249 # Number of stores squashed
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.iew.lsq.thread0.invAddrSwpfs 0 # Number of software prefetches ignored due to an invalid address
system.cpu.iew.lsq.thread0.blockedLoads 0 # Number of blocked loads due to partial load-store forwarding
system.cpu.iew.lsq.thread0.rescheduledLoads 0 # Number of loads that were rescheduled
system.cpu.iew.lsq.thread0.cacheBlocked 0 # Number of times an access to memory failed due to the cache being blocked
system.cpu.iew.iewIdleCycles 0 # Number of cycles IEW is idle
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.iewSquashCycles 737 # Number of cycles IEW is squashing
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.iew.iewBlockCycles 165 # Number of cycles IEW is blocking
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iew.iewUnblockCycles 13 # Number of cycles IEW is unblocking
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.iewDispatchedInsts 10031 # Number of instructions dispatched to IQ
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iew.iewDispSquashedInsts 128 # Number of squashed instructions skipped by dispatch
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.iewDispLoadInsts 2346 # Number of dispatched load instructions
system.cpu.iew.iewDispStoreInsts 1174 # Number of dispatched store instructions
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iew.iewDispNonSpecInsts 13 # Number of dispatched non-speculative instructions
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.iew.iewIQFullEvents 6 # Number of times the IQ has become full, causing a stall
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iew.iewLSQFullEvents 0 # Number of times the LSQ has become full, causing a stall
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.memOrderViolationEvents 8 # Number of memory order violations
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iew.predictedTakenIncorrect 107 # Number of branches that were predicted taken incorrectly
system.cpu.iew.predictedNotTakenIncorrect 309 # Number of branches that were predicted not taken incorrectly
system.cpu.iew.branchMispredicts 416 # Number of branch mispredicts detected at execute
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.iewExecutedInsts 7531 # Number of executed instructions
system.cpu.iew.iewExecLoadInsts 2028 # Number of load instructions executed
system.cpu.iew.iewExecSquashedInsts 284 # Number of squashed instructions skipped in execute
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.iew.exec_swp 0 # number of swp insts executed
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.exec_nop 1378 # number of nop insts executed
system.cpu.iew.exec_refs 3087 # number of memory reference insts executed
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.iew.exec_branches 1271 # Number of branches executed
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.exec_stores 1059 # Number of stores executed
system.cpu.iew.exec_rate 0.306812 # Inst execution rate
system.cpu.iew.wb_sent 7210 # cumulative count of insts sent to commit
system.cpu.iew.wb_count 7118 # cumulative count of insts written-back
system.cpu.iew.wb_producers 2758 # num instructions producing a value
system.cpu.iew.wb_consumers 3946 # num instructions consuming a value
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.iew.wb_penalized 0 # number of instrctions required to write to 'other' IQ
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.wb_rate 0.289986 # insts written-back per cycle
system.cpu.iew.wb_fanout 0.698936 # average fanout of values written-back
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.iew.wb_penalized_rate 0 # fraction of instructions written-back that wrote to 'other' IQ
system.cpu.commit.commitCommittedInsts 5826 # The number of committed instructions
stats: update stats for insts/ops and master id changes
2012-02-12 23:07:43 +01:00
system.cpu.commit.commitCommittedOps 5826 # The number of committed instructions
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.commit.commitSquashedInsts 4197 # The number of squashed insts skipped by commit
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.commit.commitNonSpecStalls 10 # The number of times commit has been forced to stall to communicate backwards
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.commit.branchMispredicts 357 # The number of times a branch was mispredicted
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.commit.committed_per_cycle::samples 11871 # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::mean 0.490776 # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::stdev 1.277197 # Number of insts commited each cycle
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.commit.committed_per_cycle::underflows 0 0.00% 0.00% # Number of insts commited each cycle
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.commit.committed_per_cycle::0 9472 79.79% 79.79% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::1 966 8.14% 87.93% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::2 656 5.53% 93.45% # Number of insts commited each cycle
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.commit.committed_per_cycle::3 321 2.70% 96.16% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::4 147 1.24% 97.40% # Number of insts commited each cycle
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.commit.committed_per_cycle::5 102 0.86% 98.26% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::6 64 0.54% 98.80% # Number of insts commited each cycle
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.commit.committed_per_cycle::7 41 0.35% 99.14% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::8 102 0.86% 100.00% # Number of insts commited each cycle
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.commit.committed_per_cycle::overflows 0 0.00% 100.00% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::min_value 0 # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::max_value 8 # Number of insts commited each cycle
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.commit.committed_per_cycle::total 11871 # Number of insts commited each cycle
stats: update stats for insts/ops and master id changes
2012-02-12 23:07:43 +01:00
system.cpu.commit.committedInsts 5826 # Number of instructions committed
system.cpu.commit.committedOps 5826 # Number of ops (including micro ops) committed
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.commit.swp_count 0 # Number of s/w prefetches committed
system.cpu.commit.refs 2089 # Number of memory references committed
system.cpu.commit.loads 1164 # Number of loads committed
system.cpu.commit.membars 0 # Number of memory barriers committed
system.cpu.commit.branches 916 # Number of branches committed
system.cpu.commit.fp_insts 2 # Number of committed floating point instructions.
system.cpu.commit.int_insts 5124 # Number of committed integer instructions.
system.cpu.commit.function_calls 87 # Number of function calls committed.
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.commit.bw_lim_events 102 # number cycles where commit BW limit reached
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.commit.bw_limited 0 # number of insts not committed due to BW limits
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.rob.rob_reads 21779 # The number of ROB reads
system.cpu.rob.rob_writes 20794 # The number of ROB writes
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.timesIdled 251 # Number of times that the entire CPU went into an idle state and unscheduled itself
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.idleCycles 11938 # Total number of cycles that the CPU has spent unscheduled due to idling
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.committedInsts 5169 # Number of Instructions Simulated
stats: update stats for insts/ops and master id changes
2012-02-12 23:07:43 +01:00
system.cpu.committedOps 5169 # Number of Ops (including micro ops) Simulated
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.committedInsts_total 5169 # Number of Instructions Simulated
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.cpi 4.748694 # CPI: Cycles Per Instruction
system.cpu.cpi_total 4.748694 # CPI: Total CPI of All Threads
system.cpu.ipc 0.210584 # IPC: Instructions Per Cycle
system.cpu.ipc_total 0.210584 # IPC: Total IPC of All Threads
system.cpu.int_regfile_reads 10280 # number of integer regfile reads
system.cpu.int_regfile_writes 4987 # number of integer regfile writes
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.fp_regfile_reads 3 # number of floating regfile reads
system.cpu.fp_regfile_writes 1 # number of floating regfile writes
MIPS: Fix regressions tests
2011-09-17 18:34:03 +02:00
system.cpu.misc_regfile_reads 153 # number of misc regfile reads
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.icache.replacements 17 # number of replacements
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.icache.tagsinuse 161.224498 # Cycle average of tags in use
system.cpu.icache.total_refs 1363 # Total number of references to valid blocks.
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.icache.sampled_refs 336 # Sample count of references to valid blocks.
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.icache.avg_refs 4.056548 # Average number of references to valid blocks.
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.icache.warmup_cycle 0 # Cycle when the warmup percentage was hit.
stats: update stats for insts/ops and master id changes
2012-02-12 23:07:43 +01:00
system.cpu.icache.occ_blocks::cpu.inst 161.224498 # Average occupied blocks per requestor
system.cpu.icache.occ_percent::cpu.inst 0.078723 # Average percentage of cache occupancy
system.cpu.icache.occ_percent::total 0.078723 # Average percentage of cache occupancy
system.cpu.icache.ReadReq_hits::cpu.inst 1363 # number of ReadReq hits
system.cpu.icache.ReadReq_hits::total 1363 # number of ReadReq hits
system.cpu.icache.demand_hits::cpu.inst 1363 # number of demand (read+write) hits
system.cpu.icache.demand_hits::total 1363 # number of demand (read+write) hits
system.cpu.icache.overall_hits::cpu.inst 1363 # number of overall hits
system.cpu.icache.overall_hits::total 1363 # number of overall hits
system.cpu.icache.ReadReq_misses::cpu.inst 418 # number of ReadReq misses
system.cpu.icache.ReadReq_misses::total 418 # number of ReadReq misses
system.cpu.icache.demand_misses::cpu.inst 418 # number of demand (read+write) misses
system.cpu.icache.demand_misses::total 418 # number of demand (read+write) misses
system.cpu.icache.overall_misses::cpu.inst 418 # number of overall misses
system.cpu.icache.overall_misses::total 418 # number of overall misses
system.cpu.icache.ReadReq_miss_latency::cpu.inst 15148000 # number of ReadReq miss cycles
system.cpu.icache.ReadReq_miss_latency::total 15148000 # number of ReadReq miss cycles
system.cpu.icache.demand_miss_latency::cpu.inst 15148000 # number of demand (read+write) miss cycles
system.cpu.icache.demand_miss_latency::total 15148000 # number of demand (read+write) miss cycles
system.cpu.icache.overall_miss_latency::cpu.inst 15148000 # number of overall miss cycles
system.cpu.icache.overall_miss_latency::total 15148000 # number of overall miss cycles
system.cpu.icache.ReadReq_accesses::cpu.inst 1781 # number of ReadReq accesses(hits+misses)
system.cpu.icache.ReadReq_accesses::total 1781 # number of ReadReq accesses(hits+misses)
system.cpu.icache.demand_accesses::cpu.inst 1781 # number of demand (read+write) accesses
system.cpu.icache.demand_accesses::total 1781 # number of demand (read+write) accesses
system.cpu.icache.overall_accesses::cpu.inst 1781 # number of overall (read+write) accesses
system.cpu.icache.overall_accesses::total 1781 # number of overall (read+write) accesses
system.cpu.icache.ReadReq_miss_rate::cpu.inst 0.234700 # miss rate for ReadReq accesses
system.cpu.icache.demand_miss_rate::cpu.inst 0.234700 # miss rate for demand accesses
system.cpu.icache.overall_miss_rate::cpu.inst 0.234700 # miss rate for overall accesses
system.cpu.icache.ReadReq_avg_miss_latency::cpu.inst 36239.234450 # average ReadReq miss latency
system.cpu.icache.demand_avg_miss_latency::cpu.inst 36239.234450 # average overall miss latency
system.cpu.icache.overall_avg_miss_latency::cpu.inst 36239.234450 # average overall miss latency
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.icache.blocked_cycles::no_mshrs 0 # number of cycles access was blocked
system.cpu.icache.blocked_cycles::no_targets 0 # number of cycles access was blocked
system.cpu.icache.blocked::no_mshrs 0 # number of cycles access was blocked
system.cpu.icache.blocked::no_targets 0 # number of cycles access was blocked
system.cpu.icache.avg_blocked_cycles::no_mshrs no_value # average number of cycles each access was blocked
system.cpu.icache.avg_blocked_cycles::no_targets no_value # average number of cycles each access was blocked
system.cpu.icache.fast_writes 0 # number of fast writes performed
system.cpu.icache.cache_copies 0 # number of cache copies performed
stats: update stats for insts/ops and master id changes
2012-02-12 23:07:43 +01:00
system.cpu.icache.ReadReq_mshr_hits::cpu.inst 82 # number of ReadReq MSHR hits
system.cpu.icache.ReadReq_mshr_hits::total 82 # number of ReadReq MSHR hits
system.cpu.icache.demand_mshr_hits::cpu.inst 82 # number of demand (read+write) MSHR hits
system.cpu.icache.demand_mshr_hits::total 82 # number of demand (read+write) MSHR hits
system.cpu.icache.overall_mshr_hits::cpu.inst 82 # number of overall MSHR hits
system.cpu.icache.overall_mshr_hits::total 82 # number of overall MSHR hits
system.cpu.icache.ReadReq_mshr_misses::cpu.inst 336 # number of ReadReq MSHR misses
system.cpu.icache.ReadReq_mshr_misses::total 336 # number of ReadReq MSHR misses
system.cpu.icache.demand_mshr_misses::cpu.inst 336 # number of demand (read+write) MSHR misses
system.cpu.icache.demand_mshr_misses::total 336 # number of demand (read+write) MSHR misses
system.cpu.icache.overall_mshr_misses::cpu.inst 336 # number of overall MSHR misses
system.cpu.icache.overall_mshr_misses::total 336 # number of overall MSHR misses
system.cpu.icache.ReadReq_mshr_miss_latency::cpu.inst 11784000 # number of ReadReq MSHR miss cycles
system.cpu.icache.ReadReq_mshr_miss_latency::total 11784000 # number of ReadReq MSHR miss cycles
system.cpu.icache.demand_mshr_miss_latency::cpu.inst 11784000 # number of demand (read+write) MSHR miss cycles
system.cpu.icache.demand_mshr_miss_latency::total 11784000 # number of demand (read+write) MSHR miss cycles
system.cpu.icache.overall_mshr_miss_latency::cpu.inst 11784000 # number of overall MSHR miss cycles
system.cpu.icache.overall_mshr_miss_latency::total 11784000 # number of overall MSHR miss cycles
system.cpu.icache.ReadReq_mshr_miss_rate::cpu.inst 0.188658 # mshr miss rate for ReadReq accesses
system.cpu.icache.demand_mshr_miss_rate::cpu.inst 0.188658 # mshr miss rate for demand accesses
system.cpu.icache.overall_mshr_miss_rate::cpu.inst 0.188658 # mshr miss rate for overall accesses
system.cpu.icache.ReadReq_avg_mshr_miss_latency::cpu.inst 35071.428571 # average ReadReq mshr miss latency
system.cpu.icache.demand_avg_mshr_miss_latency::cpu.inst 35071.428571 # average overall mshr miss latency
system.cpu.icache.overall_avg_mshr_miss_latency::cpu.inst 35071.428571 # average overall mshr miss latency
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.icache.no_allocate_misses 0 # Number of misses that were no-allocate
system.cpu.dcache.replacements 0 # number of replacements
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.tagsinuse 92.121984 # Cycle average of tags in use
system.cpu.dcache.total_refs 2380 # Total number of references to valid blocks.
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.sampled_refs 142 # Sample count of references to valid blocks.
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.avg_refs 16.760563 # Average number of references to valid blocks.
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.dcache.warmup_cycle 0 # Cycle when the warmup percentage was hit.
stats: update stats for insts/ops and master id changes
2012-02-12 23:07:43 +01:00
system.cpu.dcache.occ_blocks::cpu.data 92.121984 # Average occupied blocks per requestor
system.cpu.dcache.occ_percent::cpu.data 0.022491 # Average percentage of cache occupancy
system.cpu.dcache.occ_percent::total 0.022491 # Average percentage of cache occupancy
system.cpu.dcache.ReadReq_hits::cpu.data 1802 # number of ReadReq hits
system.cpu.dcache.ReadReq_hits::total 1802 # number of ReadReq hits
system.cpu.dcache.WriteReq_hits::cpu.data 578 # number of WriteReq hits
system.cpu.dcache.WriteReq_hits::total 578 # number of WriteReq hits
system.cpu.dcache.demand_hits::cpu.data 2380 # number of demand (read+write) hits
system.cpu.dcache.demand_hits::total 2380 # number of demand (read+write) hits
system.cpu.dcache.overall_hits::cpu.data 2380 # number of overall hits
system.cpu.dcache.overall_hits::total 2380 # number of overall hits
system.cpu.dcache.ReadReq_misses::cpu.data 133 # number of ReadReq misses
system.cpu.dcache.ReadReq_misses::total 133 # number of ReadReq misses
system.cpu.dcache.WriteReq_misses::cpu.data 347 # number of WriteReq misses
system.cpu.dcache.WriteReq_misses::total 347 # number of WriteReq misses
system.cpu.dcache.demand_misses::cpu.data 480 # number of demand (read+write) misses
system.cpu.dcache.demand_misses::total 480 # number of demand (read+write) misses
system.cpu.dcache.overall_misses::cpu.data 480 # number of overall misses
system.cpu.dcache.overall_misses::total 480 # number of overall misses
system.cpu.dcache.ReadReq_miss_latency::cpu.data 4767500 # number of ReadReq miss cycles
system.cpu.dcache.ReadReq_miss_latency::total 4767500 # number of ReadReq miss cycles
system.cpu.dcache.WriteReq_miss_latency::cpu.data 11508000 # number of WriteReq miss cycles
system.cpu.dcache.WriteReq_miss_latency::total 11508000 # number of WriteReq miss cycles
system.cpu.dcache.demand_miss_latency::cpu.data 16275500 # number of demand (read+write) miss cycles
system.cpu.dcache.demand_miss_latency::total 16275500 # number of demand (read+write) miss cycles
system.cpu.dcache.overall_miss_latency::cpu.data 16275500 # number of overall miss cycles
system.cpu.dcache.overall_miss_latency::total 16275500 # number of overall miss cycles
system.cpu.dcache.ReadReq_accesses::cpu.data 1935 # number of ReadReq accesses(hits+misses)
system.cpu.dcache.ReadReq_accesses::total 1935 # number of ReadReq accesses(hits+misses)
system.cpu.dcache.WriteReq_accesses::cpu.data 925 # number of WriteReq accesses(hits+misses)
system.cpu.dcache.WriteReq_accesses::total 925 # number of WriteReq accesses(hits+misses)
system.cpu.dcache.demand_accesses::cpu.data 2860 # number of demand (read+write) accesses
system.cpu.dcache.demand_accesses::total 2860 # number of demand (read+write) accesses
system.cpu.dcache.overall_accesses::cpu.data 2860 # number of overall (read+write) accesses
system.cpu.dcache.overall_accesses::total 2860 # number of overall (read+write) accesses
system.cpu.dcache.ReadReq_miss_rate::cpu.data 0.068734 # miss rate for ReadReq accesses
system.cpu.dcache.WriteReq_miss_rate::cpu.data 0.375135 # miss rate for WriteReq accesses
system.cpu.dcache.demand_miss_rate::cpu.data 0.167832 # miss rate for demand accesses
system.cpu.dcache.overall_miss_rate::cpu.data 0.167832 # miss rate for overall accesses
system.cpu.dcache.ReadReq_avg_miss_latency::cpu.data 35845.864662 # average ReadReq miss latency
system.cpu.dcache.WriteReq_avg_miss_latency::cpu.data 33164.265130 # average WriteReq miss latency
system.cpu.dcache.demand_avg_miss_latency::cpu.data 33907.291667 # average overall miss latency
system.cpu.dcache.overall_avg_miss_latency::cpu.data 33907.291667 # average overall miss latency
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.dcache.blocked_cycles::no_mshrs 0 # number of cycles access was blocked
system.cpu.dcache.blocked_cycles::no_targets 0 # number of cycles access was blocked
system.cpu.dcache.blocked::no_mshrs 0 # number of cycles access was blocked
system.cpu.dcache.blocked::no_targets 0 # number of cycles access was blocked
system.cpu.dcache.avg_blocked_cycles::no_mshrs no_value # average number of cycles each access was blocked
system.cpu.dcache.avg_blocked_cycles::no_targets no_value # average number of cycles each access was blocked
system.cpu.dcache.fast_writes 0 # number of fast writes performed
system.cpu.dcache.cache_copies 0 # number of cache copies performed
stats: update stats for insts/ops and master id changes
2012-02-12 23:07:43 +01:00
system.cpu.dcache.ReadReq_mshr_hits::cpu.data 42 # number of ReadReq MSHR hits
system.cpu.dcache.ReadReq_mshr_hits::total 42 # number of ReadReq MSHR hits
system.cpu.dcache.WriteReq_mshr_hits::cpu.data 296 # number of WriteReq MSHR hits
system.cpu.dcache.WriteReq_mshr_hits::total 296 # number of WriteReq MSHR hits
system.cpu.dcache.demand_mshr_hits::cpu.data 338 # number of demand (read+write) MSHR hits
system.cpu.dcache.demand_mshr_hits::total 338 # number of demand (read+write) MSHR hits
system.cpu.dcache.overall_mshr_hits::cpu.data 338 # number of overall MSHR hits
system.cpu.dcache.overall_mshr_hits::total 338 # number of overall MSHR hits
system.cpu.dcache.ReadReq_mshr_misses::cpu.data 91 # number of ReadReq MSHR misses
system.cpu.dcache.ReadReq_mshr_misses::total 91 # number of ReadReq MSHR misses
system.cpu.dcache.WriteReq_mshr_misses::cpu.data 51 # number of WriteReq MSHR misses
system.cpu.dcache.WriteReq_mshr_misses::total 51 # number of WriteReq MSHR misses
system.cpu.dcache.demand_mshr_misses::cpu.data 142 # number of demand (read+write) MSHR misses
system.cpu.dcache.demand_mshr_misses::total 142 # number of demand (read+write) MSHR misses
system.cpu.dcache.overall_mshr_misses::cpu.data 142 # number of overall MSHR misses
system.cpu.dcache.overall_mshr_misses::total 142 # number of overall MSHR misses
system.cpu.dcache.ReadReq_mshr_miss_latency::cpu.data 3272000 # number of ReadReq MSHR miss cycles
system.cpu.dcache.ReadReq_mshr_miss_latency::total 3272000 # number of ReadReq MSHR miss cycles
system.cpu.dcache.WriteReq_mshr_miss_latency::cpu.data 1836000 # number of WriteReq MSHR miss cycles
system.cpu.dcache.WriteReq_mshr_miss_latency::total 1836000 # number of WriteReq MSHR miss cycles
system.cpu.dcache.demand_mshr_miss_latency::cpu.data 5108000 # number of demand (read+write) MSHR miss cycles
system.cpu.dcache.demand_mshr_miss_latency::total 5108000 # number of demand (read+write) MSHR miss cycles
system.cpu.dcache.overall_mshr_miss_latency::cpu.data 5108000 # number of overall MSHR miss cycles
system.cpu.dcache.overall_mshr_miss_latency::total 5108000 # number of overall MSHR miss cycles
system.cpu.dcache.ReadReq_mshr_miss_rate::cpu.data 0.047028 # mshr miss rate for ReadReq accesses
system.cpu.dcache.WriteReq_mshr_miss_rate::cpu.data 0.055135 # mshr miss rate for WriteReq accesses
system.cpu.dcache.demand_mshr_miss_rate::cpu.data 0.049650 # mshr miss rate for demand accesses
system.cpu.dcache.overall_mshr_miss_rate::cpu.data 0.049650 # mshr miss rate for overall accesses
system.cpu.dcache.ReadReq_avg_mshr_miss_latency::cpu.data 35956.043956 # average ReadReq mshr miss latency
system.cpu.dcache.WriteReq_avg_mshr_miss_latency::cpu.data 36000 # average WriteReq mshr miss latency
system.cpu.dcache.demand_avg_mshr_miss_latency::cpu.data 35971.830986 # average overall mshr miss latency
system.cpu.dcache.overall_avg_mshr_miss_latency::cpu.data 35971.830986 # average overall mshr miss latency
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.dcache.no_allocate_misses 0 # Number of misses that were no-allocate
system.cpu.l2cache.replacements 0 # number of replacements
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.tagsinuse 221.521956 # Cycle average of tags in use
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.l2cache.total_refs 3 # Total number of references to valid blocks.
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.l2cache.sampled_refs 424 # Sample count of references to valid blocks.
system.cpu.l2cache.avg_refs 0.007075 # Average number of references to valid blocks.
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.l2cache.warmup_cycle 0 # Cycle when the warmup percentage was hit.
stats: update stats for insts/ops and master id changes
2012-02-12 23:07:43 +01:00
system.cpu.l2cache.occ_blocks::cpu.inst 163.434563 # Average occupied blocks per requestor
system.cpu.l2cache.occ_blocks::cpu.data 58.087393 # Average occupied blocks per requestor
system.cpu.l2cache.occ_percent::cpu.inst 0.004988 # Average percentage of cache occupancy
system.cpu.l2cache.occ_percent::cpu.data 0.001773 # Average percentage of cache occupancy
system.cpu.l2cache.occ_percent::total 0.006760 # Average percentage of cache occupancy
system.cpu.l2cache.ReadReq_hits::cpu.inst 3 # number of ReadReq hits
system.cpu.l2cache.ReadReq_hits::total 3 # number of ReadReq hits
system.cpu.l2cache.demand_hits::cpu.inst 3 # number of demand (read+write) hits
system.cpu.l2cache.demand_hits::total 3 # number of demand (read+write) hits
system.cpu.l2cache.overall_hits::cpu.inst 3 # number of overall hits
system.cpu.l2cache.overall_hits::total 3 # number of overall hits
system.cpu.l2cache.ReadReq_misses::cpu.inst 333 # number of ReadReq misses
system.cpu.l2cache.ReadReq_misses::cpu.data 91 # number of ReadReq misses
system.cpu.l2cache.ReadReq_misses::total 424 # number of ReadReq misses
system.cpu.l2cache.ReadExReq_misses::cpu.data 51 # number of ReadExReq misses
system.cpu.l2cache.ReadExReq_misses::total 51 # number of ReadExReq misses
system.cpu.l2cache.demand_misses::cpu.inst 333 # number of demand (read+write) misses
system.cpu.l2cache.demand_misses::cpu.data 142 # number of demand (read+write) misses
system.cpu.l2cache.demand_misses::total 475 # number of demand (read+write) misses
system.cpu.l2cache.overall_misses::cpu.inst 333 # number of overall misses
system.cpu.l2cache.overall_misses::cpu.data 142 # number of overall misses
system.cpu.l2cache.overall_misses::total 475 # number of overall misses
system.cpu.l2cache.ReadReq_miss_latency::cpu.inst 11418500 # number of ReadReq miss cycles
system.cpu.l2cache.ReadReq_miss_latency::cpu.data 3142500 # number of ReadReq miss cycles
system.cpu.l2cache.ReadReq_miss_latency::total 14561000 # number of ReadReq miss cycles
system.cpu.l2cache.ReadExReq_miss_latency::cpu.data 1760500 # number of ReadExReq miss cycles
system.cpu.l2cache.ReadExReq_miss_latency::total 1760500 # number of ReadExReq miss cycles
system.cpu.l2cache.demand_miss_latency::cpu.inst 11418500 # number of demand (read+write) miss cycles
system.cpu.l2cache.demand_miss_latency::cpu.data 4903000 # number of demand (read+write) miss cycles
system.cpu.l2cache.demand_miss_latency::total 16321500 # number of demand (read+write) miss cycles
system.cpu.l2cache.overall_miss_latency::cpu.inst 11418500 # number of overall miss cycles
system.cpu.l2cache.overall_miss_latency::cpu.data 4903000 # number of overall miss cycles
system.cpu.l2cache.overall_miss_latency::total 16321500 # number of overall miss cycles
system.cpu.l2cache.ReadReq_accesses::cpu.inst 336 # number of ReadReq accesses(hits+misses)
system.cpu.l2cache.ReadReq_accesses::cpu.data 91 # number of ReadReq accesses(hits+misses)
system.cpu.l2cache.ReadReq_accesses::total 427 # number of ReadReq accesses(hits+misses)
system.cpu.l2cache.ReadExReq_accesses::cpu.data 51 # number of ReadExReq accesses(hits+misses)
system.cpu.l2cache.ReadExReq_accesses::total 51 # number of ReadExReq accesses(hits+misses)
system.cpu.l2cache.demand_accesses::cpu.inst 336 # number of demand (read+write) accesses
system.cpu.l2cache.demand_accesses::cpu.data 142 # number of demand (read+write) accesses
system.cpu.l2cache.demand_accesses::total 478 # number of demand (read+write) accesses
system.cpu.l2cache.overall_accesses::cpu.inst 336 # number of overall (read+write) accesses
system.cpu.l2cache.overall_accesses::cpu.data 142 # number of overall (read+write) accesses
system.cpu.l2cache.overall_accesses::total 478 # number of overall (read+write) accesses
system.cpu.l2cache.ReadReq_miss_rate::cpu.inst 0.991071 # miss rate for ReadReq accesses
system.cpu.l2cache.ReadReq_miss_rate::cpu.data 1 # miss rate for ReadReq accesses
system.cpu.l2cache.ReadExReq_miss_rate::cpu.data 1 # miss rate for ReadExReq accesses
system.cpu.l2cache.demand_miss_rate::cpu.inst 0.991071 # miss rate for demand accesses
system.cpu.l2cache.demand_miss_rate::cpu.data 1 # miss rate for demand accesses
system.cpu.l2cache.overall_miss_rate::cpu.inst 0.991071 # miss rate for overall accesses
system.cpu.l2cache.overall_miss_rate::cpu.data 1 # miss rate for overall accesses
system.cpu.l2cache.ReadReq_avg_miss_latency::cpu.inst 34289.789790 # average ReadReq miss latency
system.cpu.l2cache.ReadReq_avg_miss_latency::cpu.data 34532.967033 # average ReadReq miss latency
system.cpu.l2cache.ReadExReq_avg_miss_latency::cpu.data 34519.607843 # average ReadExReq miss latency
system.cpu.l2cache.demand_avg_miss_latency::cpu.inst 34289.789790 # average overall miss latency
system.cpu.l2cache.demand_avg_miss_latency::cpu.data 34528.169014 # average overall miss latency
system.cpu.l2cache.overall_avg_miss_latency::cpu.inst 34289.789790 # average overall miss latency
system.cpu.l2cache.overall_avg_miss_latency::cpu.data 34528.169014 # average overall miss latency
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.l2cache.blocked_cycles::no_mshrs 0 # number of cycles access was blocked
system.cpu.l2cache.blocked_cycles::no_targets 0 # number of cycles access was blocked
system.cpu.l2cache.blocked::no_mshrs 0 # number of cycles access was blocked
system.cpu.l2cache.blocked::no_targets 0 # number of cycles access was blocked
system.cpu.l2cache.avg_blocked_cycles::no_mshrs no_value # average number of cycles each access was blocked
system.cpu.l2cache.avg_blocked_cycles::no_targets no_value # average number of cycles each access was blocked
system.cpu.l2cache.fast_writes 0 # number of fast writes performed
system.cpu.l2cache.cache_copies 0 # number of cache copies performed
stats: update stats for insts/ops and master id changes
2012-02-12 23:07:43 +01:00
system.cpu.l2cache.ReadReq_mshr_misses::cpu.inst 333 # number of ReadReq MSHR misses
system.cpu.l2cache.ReadReq_mshr_misses::cpu.data 91 # number of ReadReq MSHR misses
system.cpu.l2cache.ReadReq_mshr_misses::total 424 # number of ReadReq MSHR misses
system.cpu.l2cache.ReadExReq_mshr_misses::cpu.data 51 # number of ReadExReq MSHR misses
system.cpu.l2cache.ReadExReq_mshr_misses::total 51 # number of ReadExReq MSHR misses
system.cpu.l2cache.demand_mshr_misses::cpu.inst 333 # number of demand (read+write) MSHR misses
system.cpu.l2cache.demand_mshr_misses::cpu.data 142 # number of demand (read+write) MSHR misses
system.cpu.l2cache.demand_mshr_misses::total 475 # number of demand (read+write) MSHR misses
system.cpu.l2cache.overall_mshr_misses::cpu.inst 333 # number of overall MSHR misses
system.cpu.l2cache.overall_mshr_misses::cpu.data 142 # number of overall MSHR misses
system.cpu.l2cache.overall_mshr_misses::total 475 # number of overall MSHR misses
system.cpu.l2cache.ReadReq_mshr_miss_latency::cpu.inst 10340500 # number of ReadReq MSHR miss cycles
system.cpu.l2cache.ReadReq_mshr_miss_latency::cpu.data 2857500 # number of ReadReq MSHR miss cycles
system.cpu.l2cache.ReadReq_mshr_miss_latency::total 13198000 # number of ReadReq MSHR miss cycles
system.cpu.l2cache.ReadExReq_mshr_miss_latency::cpu.data 1598500 # number of ReadExReq MSHR miss cycles
system.cpu.l2cache.ReadExReq_mshr_miss_latency::total 1598500 # number of ReadExReq MSHR miss cycles
system.cpu.l2cache.demand_mshr_miss_latency::cpu.inst 10340500 # number of demand (read+write) MSHR miss cycles
system.cpu.l2cache.demand_mshr_miss_latency::cpu.data 4456000 # number of demand (read+write) MSHR miss cycles
system.cpu.l2cache.demand_mshr_miss_latency::total 14796500 # number of demand (read+write) MSHR miss cycles
system.cpu.l2cache.overall_mshr_miss_latency::cpu.inst 10340500 # number of overall MSHR miss cycles
system.cpu.l2cache.overall_mshr_miss_latency::cpu.data 4456000 # number of overall MSHR miss cycles
system.cpu.l2cache.overall_mshr_miss_latency::total 14796500 # number of overall MSHR miss cycles
system.cpu.l2cache.ReadReq_mshr_miss_rate::cpu.inst 0.991071 # mshr miss rate for ReadReq accesses
system.cpu.l2cache.ReadReq_mshr_miss_rate::cpu.data 1 # mshr miss rate for ReadReq accesses
system.cpu.l2cache.ReadExReq_mshr_miss_rate::cpu.data 1 # mshr miss rate for ReadExReq accesses
system.cpu.l2cache.demand_mshr_miss_rate::cpu.inst 0.991071 # mshr miss rate for demand accesses
system.cpu.l2cache.demand_mshr_miss_rate::cpu.data 1 # mshr miss rate for demand accesses
system.cpu.l2cache.overall_mshr_miss_rate::cpu.inst 0.991071 # mshr miss rate for overall accesses
system.cpu.l2cache.overall_mshr_miss_rate::cpu.data 1 # mshr miss rate for overall accesses
system.cpu.l2cache.ReadReq_avg_mshr_miss_latency::cpu.inst 31052.552553 # average ReadReq mshr miss latency
system.cpu.l2cache.ReadReq_avg_mshr_miss_latency::cpu.data 31401.098901 # average ReadReq mshr miss latency
system.cpu.l2cache.ReadExReq_avg_mshr_miss_latency::cpu.data 31343.137255 # average ReadExReq mshr miss latency
system.cpu.l2cache.demand_avg_mshr_miss_latency::cpu.inst 31052.552553 # average overall mshr miss latency
system.cpu.l2cache.demand_avg_mshr_miss_latency::cpu.data 31380.281690 # average overall mshr miss latency
system.cpu.l2cache.overall_avg_mshr_miss_latency::cpu.inst 31052.552553 # average overall mshr miss latency
system.cpu.l2cache.overall_avg_mshr_miss_latency::cpu.data 31380.281690 # average overall mshr miss latency
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.l2cache.no_allocate_misses 0 # Number of misses that were no-allocate
o3-mips-regress: add hello word regression.
2009-04-18 16:42:29 +02:00
---------- End Simulation Statistics ----------
Reference in a new issue Copy permalink