sanchayanmaity/gem5
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
gem5/tests/long/00.gzip/ref/alpha/tru64/o3-timing/stats.txt

518 lines
58 KiB
Text
Raw Normal View History

config file updates --HG-- extra : convert_revision : b873e0b436d71d86b87b8d9df7115bcc7ceb2b50
2006-10-12 21:04:14 +02:00
---------- Begin Simulation Statistics ----------
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
sim_seconds 0.144450 # Number of seconds simulated
sim_ticks 144450185500 # Number of ticks simulated
stats: Update stats for final tick and memory bandwidth patches
2012-01-25 18:19:50 +01:00
final_tick 144450185500 # 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 final tick and memory bandwidth patches
2012-01-25 18:19:50 +01:00
host_inst_rate 205040 # Simulator instruction rate (inst/s)
host_tick_rate 52370107 # Simulator tick rate (ticks/s)
host_mem_usage 208620 # Number of bytes of host memory used
host_seconds 2758.26 # 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 565552443 # Number of instructions simulated
stats: Update stats for final tick and memory bandwidth patches
2012-01-25 18:19:50 +01:00
system.physmem.bytes_read 5936768 # Number of bytes read from this memory
system.physmem.bytes_inst_read 60416 # Number of instructions bytes read from this memory
system.physmem.bytes_written 3797120 # Number of bytes written to this memory
system.physmem.num_reads 92762 # Number of read requests responded to by this memory
system.physmem.num_writes 59330 # 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 41099068 # Total read bandwidth from this memory (bytes/s)
system.physmem.bw_inst_read 418248 # Instruction read bandwidth from this memory (bytes/s)
system.physmem.bw_write 26286709 # Write bandwidth from this memory (bytes/s)
system.physmem.bw_total 67385777 # Total bandwidth to/from this memory (bytes/s)
tests: update tests for TLB unification
2009-04-09 07:21:30 +02:00
system.cpu.dtb.fetch_hits 0 # ITB hits
system.cpu.dtb.fetch_misses 0 # ITB 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.fetch_acv 0 # ITB acv
system.cpu.dtb.fetch_accesses 0 # ITB accesses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dtb.read_hits 125584378 # DTB read hits
system.cpu.dtb.read_misses 26780 # 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_acv 0 # DTB read access violations
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dtb.read_accesses 125611158 # DTB read accesses
system.cpu.dtb.write_hits 41433696 # DTB write hits
system.cpu.dtb.write_misses 32002 # DTB write misses
StoreSet: Update stats for store-set clearing
2011-08-19 22:08:08 +02:00
system.cpu.dtb.write_acv 0 # DTB write access violations
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dtb.write_accesses 41465698 # DTB write accesses
system.cpu.dtb.data_hits 167018074 # DTB hits
system.cpu.dtb.data_misses 58782 # DTB misses
StoreSet: Update stats for store-set clearing
2011-08-19 22:08:08 +02:00
system.cpu.dtb.data_acv 0 # DTB access violations
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dtb.data_accesses 167076856 # DTB accesses
system.cpu.itb.fetch_hits 70952399 # ITB hits
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.itb.fetch_misses 40 # ITB 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.itb.fetch_acv 0 # ITB acv
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.itb.fetch_accesses 70952439 # ITB 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.itb.read_hits 0 # DTB read hits
system.cpu.itb.read_misses 0 # DTB read misses
system.cpu.itb.read_acv 0 # DTB read access violations
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_acv 0 # DTB write access violations
system.cpu.itb.write_accesses 0 # DTB write accesses
system.cpu.itb.data_hits 0 # DTB hits
system.cpu.itb.data_misses 0 # DTB misses
system.cpu.itb.data_acv 0 # DTB access violations
system.cpu.itb.data_accesses 0 # DTB accesses
system.cpu.workload.num_syscalls 17 # Number of system calls
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.numCycles 288900372 # 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 81329377 # Number of BP lookups
system.cpu.BPredUnit.condPredicted 74804974 # Number of conditional branches predicted
system.cpu.BPredUnit.condIncorrect 4133006 # Number of conditional branches incorrect
system.cpu.BPredUnit.BTBLookups 77032590 # Number of BTB lookups
system.cpu.BPredUnit.BTBHits 69317648 # 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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.BPredUnit.usedRAS 1953991 # Number of times the RAS was used to get a target.
system.cpu.BPredUnit.RASInCorrect 213 # Number of incorrect RAS predictions.
system.cpu.fetch.icacheStallCycles 73654881 # Number of cycles fetch is stalled on an Icache miss
system.cpu.fetch.Insts 736311086 # Number of instructions fetch has processed
system.cpu.fetch.Branches 81329377 # Number of branches that fetch encountered
system.cpu.fetch.predictedBranches 71271639 # Number of branches that fetch has predicted taken
system.cpu.fetch.Cycles 138478958 # Number of cycles fetch has run and was not squashing or blocked
system.cpu.fetch.SquashCycles 16551941 # Number of cycles fetch has spent squashing
system.cpu.fetch.BlockedCycles 64286783 # Number of cycles fetch has spent blocked
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.fetch.MiscStallCycles 31 # Number of cycles fetch has spent waiting on interrupts, or bad addresses, or out of MSHRs
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.fetch.PendingTrapStallCycles 957 # 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 70952399 # Number of cache lines fetched
system.cpu.fetch.IcacheSquashes 1183706 # Number of outstanding Icache misses that were squashed
system.cpu.fetch.rateDist::samples 288831482 # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::mean 2.549276 # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::stdev 3.199825 # 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 150352524 52.06% 52.06% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::1 11670569 4.04% 56.10% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::2 15804098 5.47% 61.57% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::3 15798949 5.47% 67.04% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::4 13114109 4.54% 71.58% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::5 15608541 5.40% 76.98% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::6 6620136 2.29% 79.27% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::7 3484931 1.21% 80.48% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::8 56377625 19.52% 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 288831482 # Number of instructions fetched each cycle (Total)
system.cpu.fetch.branchRate 0.281514 # Number of branch fetches per cycle
system.cpu.fetch.rate 2.548668 # Number of inst fetches per cycle
system.cpu.decode.IdleCycles 89767727 # Number of cycles decode is idle
system.cpu.decode.BlockedCycles 50572891 # Number of cycles decode is blocked
system.cpu.decode.RunCycles 125759213 # Number of cycles decode is running
system.cpu.decode.UnblockCycles 10322601 # Number of cycles decode is unblocking
system.cpu.decode.SquashCycles 12409050 # Number of cycles decode is squashing
system.cpu.decode.BranchResolved 4445174 # Number of times decode resolved a branch
system.cpu.decode.BranchMispred 884 # Number of times decode detected a branch misprediction
system.cpu.decode.DecodedInsts 724769065 # Number of instructions handled by decode
system.cpu.decode.SquashedInsts 3300 # Number of squashed instructions handled by decode
system.cpu.rename.SquashCycles 12409050 # Number of cycles rename is squashing
system.cpu.rename.IdleCycles 98007088 # Number of cycles rename is idle
system.cpu.rename.BlockCycles 12678191 # Number of cycles rename is blocking
system.cpu.rename.serializeStallCycles 619 # count of cycles rename stalled for serializing inst
system.cpu.rename.RunCycles 122576240 # Number of cycles rename is running
system.cpu.rename.UnblockCycles 43160294 # Number of cycles rename is unblocking
system.cpu.rename.RenamedInsts 711155131 # Number of instructions processed by rename
system.cpu.rename.ROBFullEvents 265 # Number of times rename has blocked due to ROB full
system.cpu.rename.IQFullEvents 33840558 # Number of times rename has blocked due to IQ full
system.cpu.rename.LSQFullEvents 3866582 # Number of times rename has blocked due to LSQ full
system.cpu.rename.RenamedOperands 542435988 # Number of destination operands rename has renamed
system.cpu.rename.RenameLookups 934956599 # Number of register rename lookups that rename has made
system.cpu.rename.int_rename_lookups 934954553 # Number of integer rename lookups
system.cpu.rename.fp_rename_lookups 2046 # 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 463854889 # 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 78581099 # Number of HB maps that are undone due to squashing
system.cpu.rename.serializingInsts 37 # count of serializing insts renamed
system.cpu.rename.tempSerializingInsts 37 # count of temporary serializing insts renamed
system.cpu.rename.skidInsts 84659517 # count of insts added to the skid buffer
system.cpu.memDep0.insertedLoads 130961315 # Number of loads inserted to the mem dependence unit.
system.cpu.memDep0.insertedStores 43800509 # Number of stores inserted to the mem dependence unit.
system.cpu.memDep0.conflictingLoads 14632120 # Number of conflicting loads.
system.cpu.memDep0.conflictingStores 10811841 # Number of conflicting stores.
system.cpu.iq.iqInstsAdded 641773186 # Number of instructions added to the IQ (excludes non-spec)
StoreSet: Update stats for store-set clearing
2011-08-19 22:08:08 +02:00
system.cpu.iq.iqNonSpecInstsAdded 30 # 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 620620587 # Number of instructions issued
system.cpu.iq.iqSquashedInstsIssued 312645 # Number of squashed instructions issued
system.cpu.iq.iqSquashedInstsExamined 75146534 # Number of squashed instructions iterated over during squash; mainly for profiling
system.cpu.iq.iqSquashedOperandsExamined 39896926 # Number of squashed operands that are examined and possibly removed from graph
StoreSet: Update stats for store-set clearing
2011-08-19 22:08:08 +02:00
system.cpu.iq.iqSquashedNonSpecRemoved 13 # 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 288831482 # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::mean 2.148729 # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::stdev 1.863512 # 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 69246295 23.97% 23.97% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::1 56834943 19.68% 43.65% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::2 56336980 19.51% 63.16% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::3 34937865 12.10% 75.25% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::4 31450731 10.89% 86.14% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::5 24967668 8.64% 94.79% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::6 10438059 3.61% 98.40% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::7 3923057 1.36% 99.76% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::8 695884 0.24% 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 288831482 # 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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iq.fu_full::IntAlu 3711133 78.36% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::IntMult 47 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::IntDiv 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatAdd 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatCmp 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatCvt 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatMult 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatDiv 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatSqrt 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdAdd 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdAddAcc 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdAlu 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdCmp 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdCvt 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdMisc 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdMult 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdMultAcc 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdShift 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdShiftAcc 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdSqrt 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatAdd 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatAlu 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatCmp 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatCvt 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatDiv 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatMisc 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatMult 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatMultAcc 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatSqrt 0 0.00% 78.36% # attempts to use FU when none available
system.cpu.iq.fu_full::MemRead 592679 12.51% 90.88% # attempts to use FU when none available
system.cpu.iq.fu_full::MemWrite 432117 9.12% 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 450541493 72.60% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::IntMult 7929 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::IntDiv 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::FloatAdd 32 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::FloatCmp 6 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::FloatCvt 5 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::FloatMult 5 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::FloatDiv 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::FloatSqrt 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdAdd 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdAddAcc 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdAlu 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdCmp 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdCvt 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdMisc 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdMult 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdMultAcc 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdShift 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdShiftAcc 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdSqrt 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatAdd 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatAlu 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatCmp 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatCvt 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatDiv 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatMisc 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatMult 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatMultAcc 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatSqrt 0 0.00% 72.60% # Type of FU issued
system.cpu.iq.FU_type_0::MemRead 127924018 20.61% 93.21% # Type of FU issued
system.cpu.iq.FU_type_0::MemWrite 42147099 6.79% 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 620620587 # Type of FU issued
system.cpu.iq.rate 2.148217 # Inst issue rate
system.cpu.iq.fu_busy_cnt 4735976 # FU busy when requested
system.cpu.iq.fu_busy_rate 0.007631 # FU busy rate (busy events/executed inst)
system.cpu.iq.int_inst_queue_reads 1535117897 # Number of integer instruction queue reads
system.cpu.iq.int_inst_queue_writes 716922572 # Number of integer instruction queue writes
system.cpu.iq.int_inst_queue_wakeup_accesses 608986825 # Number of integer instruction queue wakeup accesses
system.cpu.iq.fp_inst_queue_reads 3380 # Number of floating instruction queue reads
system.cpu.iq.fp_inst_queue_writes 1870 # Number of floating instruction queue writes
system.cpu.iq.fp_inst_queue_wakeup_accesses 1597 # Number of floating instruction queue wakeup accesses
system.cpu.iq.int_alu_accesses 625354857 # Number of integer alu accesses
system.cpu.iq.fp_alu_accesses 1706 # Number of floating point alu accesses
system.cpu.iew.lsq.thread0.forwLoads 11780563 # 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 16447273 # Number of loads squashed
system.cpu.iew.lsq.thread0.ignoredResponses 150139 # Number of memory responses ignored because the instruction is squashed
system.cpu.iew.lsq.thread0.memOrderViolation 4778 # Number of memory ordering violations
system.cpu.iew.lsq.thread0.squashedStores 4349188 # 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
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.lsq.thread0.rescheduledLoads 5903 # Number of loads that were rescheduled
system.cpu.iew.lsq.thread0.cacheBlocked 50771 # Number of times an access to memory failed due to the cache being blocked
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.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 12409050 # Number of cycles IEW is squashing
system.cpu.iew.iewBlockCycles 1537752 # Number of cycles IEW is blocking
system.cpu.iew.iewUnblockCycles 101062 # Number of cycles IEW is unblocking
system.cpu.iew.iewDispatchedInsts 686807741 # Number of instructions dispatched to IQ
system.cpu.iew.iewDispSquashedInsts 2379158 # Number of squashed instructions skipped by dispatch
system.cpu.iew.iewDispLoadInsts 130961315 # Number of dispatched load instructions
system.cpu.iew.iewDispStoreInsts 43800509 # Number of dispatched store instructions
StoreSet: Update stats for store-set clearing
2011-08-19 22:08:08 +02:00
system.cpu.iew.iewDispNonSpecInsts 30 # Number of dispatched non-speculative instructions
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.iewIQFullEvents 40948 # Number of times the IQ has become full, causing a stall
system.cpu.iew.iewLSQFullEvents 13806 # Number of times the LSQ has become full, causing a stall
system.cpu.iew.memOrderViolationEvents 4778 # Number of memory order violations
system.cpu.iew.predictedTakenIncorrect 4044271 # Number of branches that were predicted taken incorrectly
system.cpu.iew.predictedNotTakenIncorrect 603642 # Number of branches that were predicted not taken incorrectly
system.cpu.iew.branchMispredicts 4647913 # Number of branch mispredicts detected at execute
system.cpu.iew.iewExecutedInsts 613128186 # Number of executed instructions
system.cpu.iew.iewExecLoadInsts 125611295 # Number of load instructions executed
system.cpu.iew.iewExecSquashedInsts 7492401 # 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 45034525 # number of nop insts executed
system.cpu.iew.exec_refs 167096489 # number of memory reference insts executed
system.cpu.iew.exec_branches 68658345 # Number of branches executed
system.cpu.iew.exec_stores 41485194 # Number of stores executed
system.cpu.iew.exec_rate 2.122282 # Inst execution rate
system.cpu.iew.wb_sent 610318268 # cumulative count of insts sent to commit
system.cpu.iew.wb_count 608988422 # cumulative count of insts written-back
system.cpu.iew.wb_producers 420036286 # num instructions producing a value
system.cpu.iew.wb_consumers 531421352 # 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 2.107953 # insts written-back per cycle
system.cpu.iew.wb_fanout 0.790402 # 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 601856963 # The number of committed instructions
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.commit.commitSquashedInsts 84796787 # 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 17 # The number of times commit has been forced to stall to communicate backwards
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.commit.branchMispredicts 4132184 # The number of times a branch was mispredicted
system.cpu.commit.committed_per_cycle::samples 276422432 # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::mean 2.177309 # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::stdev 2.603924 # 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 90291943 32.66% 32.66% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::1 75645741 27.37% 60.03% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::2 32420379 11.73% 71.76% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::3 8741969 3.16% 74.92% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::4 10320203 3.73% 78.66% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::5 19633028 7.10% 85.76% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::6 6964693 2.52% 88.28% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::7 5325361 1.93% 90.20% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::8 27079115 9.80% 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 276422432 # 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.count 601856963 # Number of instructions committed
system.cpu.commit.swp_count 0 # Number of s/w prefetches committed
system.cpu.commit.refs 153965363 # Number of memory references committed
system.cpu.commit.loads 114514042 # Number of loads committed
system.cpu.commit.membars 0 # Number of memory barriers committed
system.cpu.commit.branches 62547159 # Number of branches committed
system.cpu.commit.fp_insts 1520 # Number of committed floating point instructions.
system.cpu.commit.int_insts 563954763 # Number of committed integer instructions.
system.cpu.commit.function_calls 1197610 # Number of function calls committed.
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.commit.bw_lim_events 27079115 # 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 935932678 # The number of ROB reads
system.cpu.rob.rob_writes 1385724156 # The number of ROB writes
system.cpu.timesIdled 2221 # Number of times that the entire CPU went into an idle state and unscheduled itself
system.cpu.idleCycles 68890 # 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 565552443 # Number of Instructions Simulated
system.cpu.committedInsts_total 565552443 # Number of Instructions Simulated
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.cpi 0.510829 # CPI: Cycles Per Instruction
system.cpu.cpi_total 0.510829 # CPI: Total CPI of All Threads
system.cpu.ipc 1.957604 # IPC: Instructions Per Cycle
system.cpu.ipc_total 1.957604 # IPC: Total IPC of All Threads
system.cpu.int_regfile_reads 863490102 # number of integer regfile reads
system.cpu.int_regfile_writes 500818441 # number of integer regfile writes
system.cpu.fp_regfile_reads 272 # number of floating regfile reads
StoreSet: Update stats for store-set clearing
2011-08-19 22:08:08 +02:00
system.cpu.fp_regfile_writes 54 # number of floating 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.misc_regfile_reads 1 # number of misc regfile reads
system.cpu.misc_regfile_writes 1 # number of misc regfile writes
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.icache.replacements 36 # number of replacements
system.cpu.icache.tagsinuse 801.236568 # Cycle average of tags in use
system.cpu.icache.total_refs 70951127 # Total number of references to valid blocks.
system.cpu.icache.sampled_refs 944 # Sample count of references to valid blocks.
system.cpu.icache.avg_refs 75160.092161 # 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.
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.icache.occ_blocks::0 801.236568 # Average occupied blocks per context
system.cpu.icache.occ_percent::0 0.391229 # Average percentage of cache occupancy
system.cpu.icache.ReadReq_hits 70951127 # number of ReadReq hits
system.cpu.icache.demand_hits 70951127 # number of demand (read+write) hits
system.cpu.icache.overall_hits 70951127 # number of overall hits
system.cpu.icache.ReadReq_misses 1272 # number of ReadReq misses
system.cpu.icache.demand_misses 1272 # number of demand (read+write) misses
system.cpu.icache.overall_misses 1272 # number of overall misses
system.cpu.icache.ReadReq_miss_latency 45919500 # number of ReadReq miss cycles
system.cpu.icache.demand_miss_latency 45919500 # number of demand (read+write) miss cycles
system.cpu.icache.overall_miss_latency 45919500 # number of overall miss cycles
system.cpu.icache.ReadReq_accesses 70952399 # number of ReadReq accesses(hits+misses)
system.cpu.icache.demand_accesses 70952399 # number of demand (read+write) accesses
system.cpu.icache.overall_accesses 70952399 # number of overall (read+write) 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.icache.ReadReq_miss_rate 0.000018 # miss rate for ReadReq accesses
system.cpu.icache.demand_miss_rate 0.000018 # miss rate for demand accesses
system.cpu.icache.overall_miss_rate 0.000018 # miss rate for overall accesses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.icache.ReadReq_avg_miss_latency 36100.235849 # average ReadReq miss latency
system.cpu.icache.demand_avg_miss_latency 36100.235849 # average overall miss latency
system.cpu.icache.overall_avg_miss_latency 36100.235849 # 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
system.cpu.icache.writebacks 0 # number of writebacks
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.icache.ReadReq_mshr_hits 328 # number of ReadReq MSHR hits
system.cpu.icache.demand_mshr_hits 328 # number of demand (read+write) MSHR hits
system.cpu.icache.overall_mshr_hits 328 # number of overall MSHR hits
system.cpu.icache.ReadReq_mshr_misses 944 # number of ReadReq MSHR misses
system.cpu.icache.demand_mshr_misses 944 # number of demand (read+write) MSHR misses
system.cpu.icache.overall_mshr_misses 944 # number of overall MSHR 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.icache.overall_mshr_uncacheable_misses 0 # number of overall MSHR uncacheable misses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.icache.ReadReq_mshr_miss_latency 33676000 # number of ReadReq MSHR miss cycles
system.cpu.icache.demand_mshr_miss_latency 33676000 # number of demand (read+write) MSHR miss cycles
system.cpu.icache.overall_mshr_miss_latency 33676000 # number of overall MSHR miss cycles
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.overall_mshr_uncacheable_latency 0 # number of overall MSHR uncacheable cycles
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.icache.ReadReq_mshr_miss_rate 0.000013 # mshr miss rate for ReadReq accesses
system.cpu.icache.demand_mshr_miss_rate 0.000013 # mshr miss rate for demand accesses
system.cpu.icache.overall_mshr_miss_rate 0.000013 # mshr miss rate for overall accesses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.icache.ReadReq_avg_mshr_miss_latency 35673.728814 # average ReadReq mshr miss latency
system.cpu.icache.demand_avg_mshr_miss_latency 35673.728814 # average overall mshr miss latency
system.cpu.icache.overall_avg_mshr_miss_latency 35673.728814 # 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.overall_avg_mshr_uncacheable_latency no_value # average overall mshr uncacheable latency
system.cpu.icache.mshr_cap_events 0 # number of times MSHR cap was activated
system.cpu.icache.soft_prefetch_mshr_full 0 # number of mshr full events for SW prefetching instrutions
system.cpu.icache.no_allocate_misses 0 # Number of misses that were no-allocate
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.replacements 470690 # number of replacements
system.cpu.dcache.tagsinuse 4093.940031 # Cycle average of tags in use
system.cpu.dcache.total_refs 151212527 # Total number of references to valid blocks.
system.cpu.dcache.sampled_refs 474786 # Sample count of references to valid blocks.
system.cpu.dcache.avg_refs 318.485648 # Average number of references to valid blocks.
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.warmup_cycle 126051000 # Cycle when the warmup percentage was hit.
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.occ_blocks::0 4093.940031 # Average occupied blocks per context
system.cpu.dcache.occ_percent::0 0.999497 # Average percentage of cache occupancy
system.cpu.dcache.ReadReq_hits 113064898 # number of ReadReq hits
system.cpu.dcache.WriteReq_hits 38147626 # number of WriteReq hits
system.cpu.dcache.LoadLockedReq_hits 3 # number of LoadLockedReq hits
system.cpu.dcache.demand_hits 151212524 # number of demand (read+write) hits
system.cpu.dcache.overall_hits 151212524 # number of overall hits
system.cpu.dcache.ReadReq_misses 732041 # number of ReadReq misses
system.cpu.dcache.WriteReq_misses 1303695 # number of WriteReq misses
system.cpu.dcache.demand_misses 2035736 # number of demand (read+write) misses
system.cpu.dcache.overall_misses 2035736 # number of overall misses
system.cpu.dcache.ReadReq_miss_latency 11783533000 # number of ReadReq miss cycles
system.cpu.dcache.WriteReq_miss_latency 19632740219 # number of WriteReq miss cycles
system.cpu.dcache.demand_miss_latency 31416273219 # number of demand (read+write) miss cycles
system.cpu.dcache.overall_miss_latency 31416273219 # number of overall miss cycles
system.cpu.dcache.ReadReq_accesses 113796939 # number of ReadReq accesses(hits+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.dcache.WriteReq_accesses 39451321 # number of WriteReq accesses(hits+misses)
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.LoadLockedReq_accesses 3 # number of LoadLockedReq accesses(hits+misses)
system.cpu.dcache.demand_accesses 153248260 # number of demand (read+write) accesses
system.cpu.dcache.overall_accesses 153248260 # number of overall (read+write) accesses
system.cpu.dcache.ReadReq_miss_rate 0.006433 # miss rate for ReadReq accesses
system.cpu.dcache.WriteReq_miss_rate 0.033046 # miss rate for WriteReq accesses
system.cpu.dcache.demand_miss_rate 0.013284 # miss rate for demand accesses
system.cpu.dcache.overall_miss_rate 0.013284 # miss rate for overall accesses
system.cpu.dcache.ReadReq_avg_miss_latency 16096.821080 # average ReadReq miss latency
system.cpu.dcache.WriteReq_avg_miss_latency 15059.304683 # average WriteReq miss latency
system.cpu.dcache.demand_avg_miss_latency 15432.390653 # average overall miss latency
system.cpu.dcache.overall_avg_miss_latency 15432.390653 # average overall miss latency
system.cpu.dcache.blocked_cycles::no_mshrs 804496 # number of cycles access was blocked
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.blocked_cycles::no_targets 236500 # number of cycles access was blocked
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.blocked::no_mshrs 116 # number of cycles access was blocked
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::no_targets 11 # number of cycles access was blocked
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.avg_blocked_cycles::no_mshrs 6935.310345 # average number of cycles each access was blocked
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.avg_blocked_cycles::no_targets 21500 # average number of cycles each access was blocked
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.fast_writes 0 # number of fast writes performed
system.cpu.dcache.cache_copies 0 # number of cache copies performed
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.writebacks 423044 # number of writebacks
system.cpu.dcache.ReadReq_mshr_hits 513277 # number of ReadReq MSHR hits
system.cpu.dcache.WriteReq_mshr_hits 1047673 # number of WriteReq MSHR hits
system.cpu.dcache.demand_mshr_hits 1560950 # number of demand (read+write) MSHR hits
system.cpu.dcache.overall_mshr_hits 1560950 # number of overall MSHR hits
system.cpu.dcache.ReadReq_mshr_misses 218764 # number of ReadReq MSHR misses
system.cpu.dcache.WriteReq_mshr_misses 256022 # number of WriteReq MSHR misses
system.cpu.dcache.demand_mshr_misses 474786 # number of demand (read+write) MSHR misses
system.cpu.dcache.overall_mshr_misses 474786 # number of overall MSHR 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.dcache.overall_mshr_uncacheable_misses 0 # number of overall MSHR uncacheable misses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.ReadReq_mshr_miss_latency 1640072500 # number of ReadReq MSHR miss cycles
system.cpu.dcache.WriteReq_mshr_miss_latency 3027658494 # number of WriteReq MSHR miss cycles
system.cpu.dcache.demand_mshr_miss_latency 4667730994 # number of demand (read+write) MSHR miss cycles
system.cpu.dcache.overall_mshr_miss_latency 4667730994 # number of overall MSHR miss cycles
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.overall_mshr_uncacheable_latency 0 # number of overall MSHR uncacheable cycles
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.ReadReq_mshr_miss_rate 0.001922 # mshr miss rate for ReadReq accesses
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.WriteReq_mshr_miss_rate 0.006490 # mshr miss rate for WriteReq accesses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.demand_mshr_miss_rate 0.003098 # mshr miss rate for demand accesses
system.cpu.dcache.overall_mshr_miss_rate 0.003098 # mshr miss rate for overall accesses
system.cpu.dcache.ReadReq_avg_mshr_miss_latency 7496.994478 # average ReadReq mshr miss latency
system.cpu.dcache.WriteReq_avg_mshr_miss_latency 11825.774715 # average WriteReq mshr miss latency
system.cpu.dcache.demand_avg_mshr_miss_latency 9831.231321 # average overall mshr miss latency
system.cpu.dcache.overall_avg_mshr_miss_latency 9831.231321 # 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.overall_avg_mshr_uncacheable_latency no_value # average overall mshr uncacheable latency
system.cpu.dcache.mshr_cap_events 0 # number of times MSHR cap was activated
system.cpu.dcache.soft_prefetch_mshr_full 0 # number of mshr full events for SW prefetching instrutions
system.cpu.dcache.no_allocate_misses 0 # Number of misses that were no-allocate
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.replacements 74463 # number of replacements
system.cpu.l2cache.tagsinuse 17661.712037 # Cycle average of tags in use
system.cpu.l2cache.total_refs 478021 # Total number of references to valid blocks.
system.cpu.l2cache.sampled_refs 90363 # Sample count of references to valid blocks.
system.cpu.l2cache.avg_refs 5.290008 # 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.
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.occ_blocks::0 1743.919943 # Average occupied blocks per context
system.cpu.l2cache.occ_blocks::1 15917.792095 # Average occupied blocks per context
system.cpu.l2cache.occ_percent::0 0.053220 # Average percentage of cache occupancy
system.cpu.l2cache.occ_percent::1 0.485772 # Average percentage of cache occupancy
system.cpu.l2cache.ReadReq_hits 186750 # number of ReadReq hits
system.cpu.l2cache.Writeback_hits 423044 # number of Writeback hits
system.cpu.l2cache.ReadExReq_hits 196218 # number of ReadExReq hits
system.cpu.l2cache.demand_hits 382968 # number of demand (read+write) hits
system.cpu.l2cache.overall_hits 382968 # number of overall hits
system.cpu.l2cache.ReadReq_misses 32958 # number of ReadReq misses
system.cpu.l2cache.ReadExReq_misses 59804 # number of ReadExReq misses
system.cpu.l2cache.demand_misses 92762 # number of demand (read+write) misses
system.cpu.l2cache.overall_misses 92762 # number of overall misses
system.cpu.l2cache.ReadReq_miss_latency 1133680000 # number of ReadReq miss cycles
system.cpu.l2cache.ReadExReq_miss_latency 2065878500 # number of ReadExReq miss cycles
system.cpu.l2cache.demand_miss_latency 3199558500 # number of demand (read+write) miss cycles
system.cpu.l2cache.overall_miss_latency 3199558500 # number of overall miss cycles
system.cpu.l2cache.ReadReq_accesses 219708 # number of ReadReq accesses(hits+misses)
system.cpu.l2cache.Writeback_accesses 423044 # number of Writeback accesses(hits+misses)
system.cpu.l2cache.ReadExReq_accesses 256022 # number of ReadExReq accesses(hits+misses)
system.cpu.l2cache.demand_accesses 475730 # number of demand (read+write) accesses
system.cpu.l2cache.overall_accesses 475730 # number of overall (read+write) accesses
system.cpu.l2cache.ReadReq_miss_rate 0.150008 # miss rate for ReadReq accesses
system.cpu.l2cache.ReadExReq_miss_rate 0.233589 # miss rate for ReadExReq accesses
system.cpu.l2cache.demand_miss_rate 0.194989 # miss rate for demand accesses
system.cpu.l2cache.overall_miss_rate 0.194989 # miss rate for overall accesses
system.cpu.l2cache.ReadReq_avg_miss_latency 34397.718308 # average ReadReq miss latency
system.cpu.l2cache.ReadExReq_avg_miss_latency 34544.152565 # average ReadExReq miss latency
system.cpu.l2cache.demand_avg_miss_latency 34492.125008 # average overall miss latency
system.cpu.l2cache.overall_avg_miss_latency 34492.125008 # average overall miss latency
system.cpu.l2cache.blocked_cycles::no_mshrs 370500 # number of cycles access was blocked
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_targets 0 # number of cycles access was blocked
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.blocked::no_mshrs 72 # number of cycles access was blocked
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::no_targets 0 # number of cycles access was blocked
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.avg_blocked_cycles::no_mshrs 5145.833333 # average number of cycles each access was blocked
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.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
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.writebacks 59330 # number of writebacks
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.demand_mshr_hits 0 # number of demand (read+write) MSHR hits
config file updates --HG-- extra : convert_revision : b873e0b436d71d86b87b8d9df7115bcc7ceb2b50
2006-10-12 21:04:14 +02:00
system.cpu.l2cache.overall_mshr_hits 0 # number of overall MSHR hits
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.ReadReq_mshr_misses 32958 # number of ReadReq MSHR misses
system.cpu.l2cache.ReadExReq_mshr_misses 59804 # number of ReadExReq MSHR misses
system.cpu.l2cache.demand_mshr_misses 92762 # number of demand (read+write) MSHR misses
system.cpu.l2cache.overall_mshr_misses 92762 # number of overall MSHR misses
config file updates --HG-- extra : convert_revision : b873e0b436d71d86b87b8d9df7115bcc7ceb2b50
2006-10-12 21:04:14 +02:00
system.cpu.l2cache.overall_mshr_uncacheable_misses 0 # number of overall MSHR uncacheable misses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.ReadReq_mshr_miss_latency 1022345000 # number of ReadReq MSHR miss cycles
system.cpu.l2cache.ReadExReq_mshr_miss_latency 1877543500 # number of ReadExReq MSHR miss cycles
system.cpu.l2cache.demand_mshr_miss_latency 2899888500 # number of demand (read+write) MSHR miss cycles
system.cpu.l2cache.overall_mshr_miss_latency 2899888500 # number of overall MSHR miss cycles
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.overall_mshr_uncacheable_latency 0 # number of overall MSHR uncacheable cycles
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.ReadReq_mshr_miss_rate 0.150008 # mshr miss rate for ReadReq accesses
system.cpu.l2cache.ReadExReq_mshr_miss_rate 0.233589 # mshr miss rate for ReadExReq accesses
system.cpu.l2cache.demand_mshr_miss_rate 0.194989 # mshr miss rate for demand accesses
system.cpu.l2cache.overall_mshr_miss_rate 0.194989 # mshr miss rate for overall accesses
system.cpu.l2cache.ReadReq_avg_mshr_miss_latency 31019.631046 # average ReadReq mshr miss latency
system.cpu.l2cache.ReadExReq_avg_mshr_miss_latency 31394.948498 # average ReadExReq mshr miss latency
system.cpu.l2cache.demand_avg_mshr_miss_latency 31261.599577 # average overall mshr miss latency
system.cpu.l2cache.overall_avg_mshr_miss_latency 31261.599577 # 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.overall_avg_mshr_uncacheable_latency no_value # average overall mshr uncacheable latency
system.cpu.l2cache.mshr_cap_events 0 # number of times MSHR cap was activated
config file updates --HG-- extra : convert_revision : b873e0b436d71d86b87b8d9df7115bcc7ceb2b50
2006-10-12 21:04:14 +02:00
system.cpu.l2cache.soft_prefetch_mshr_full 0 # number of mshr full events for SW prefetching instrutions
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
config file updates --HG-- extra : convert_revision : b873e0b436d71d86b87b8d9df7115bcc7ceb2b50
2006-10-12 21:04:14 +02:00
---------- End Simulation Statistics ----------
Reference in a new issue Copy permalink