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

516 lines
57 KiB
Plaintext
Raw Normal View History

tests: perlbmk now works. Commit stats and assume the're right. Kevin fixed how O3 handles syscalls that change NextPC (longjump).
2008-09-28 23:15:50 +02:00
---------- Begin Simulation Statistics ----------
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
sim_seconds 0.643278 # Number of seconds simulated
sim_ticks 643278327500 # Number of ticks 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
sim_freq 1000000000000 # Frequency of simulated ticks
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
host_inst_rate 72554 # Simulator instruction rate (inst/s)
host_tick_rate 25601460 # Simulator tick rate (ticks/s)
host_mem_usage 253232 # Number of bytes of host memory used
host_seconds 25126.63 # 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 1823043370 # Number of instructions simulated
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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dtb.read_hits 519966765 # DTB read hits
system.cpu.dtb.read_misses 661962 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dtb.read_accesses 520628727 # DTB read accesses
system.cpu.dtb.write_hits 283803273 # DTB write hits
system.cpu.dtb.write_misses 53019 # 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_acv 0 # DTB write access violations
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dtb.write_accesses 283856292 # DTB write accesses
system.cpu.dtb.data_hits 803770038 # DTB hits
system.cpu.dtb.data_misses 714981 # DTB 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.data_acv 0 # DTB access violations
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dtb.data_accesses 804485019 # DTB accesses
system.cpu.itb.fetch_hits 398172437 # ITB hits
system.cpu.itb.fetch_misses 227 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.itb.fetch_accesses 398172664 # 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 39 # Number of system calls
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.numCycles 1286556656 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.BPredUnit.lookups 402336394 # Number of BP lookups
system.cpu.BPredUnit.condPredicted 266883320 # Number of conditional branches predicted
system.cpu.BPredUnit.condIncorrect 28923526 # Number of conditional branches incorrect
system.cpu.BPredUnit.BTBLookups 333487818 # Number of BTB lookups
system.cpu.BPredUnit.BTBHits 271623617 # 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 61006515 # Number of times the RAS was used to get a target.
system.cpu.BPredUnit.RASInCorrect 1123 # Number of incorrect RAS predictions.
system.cpu.fetch.icacheStallCycles 414972341 # Number of cycles fetch is stalled on an Icache miss
system.cpu.fetch.Insts 3352664907 # Number of instructions fetch has processed
system.cpu.fetch.Branches 402336394 # Number of branches that fetch encountered
system.cpu.fetch.predictedBranches 332630132 # Number of branches that fetch has predicted taken
system.cpu.fetch.Cycles 645381442 # Number of cycles fetch has run and was not squashing or blocked
system.cpu.fetch.SquashCycles 165705235 # Number of cycles fetch has spent squashing
system.cpu.fetch.BlockedCycles 89720860 # Number of cycles fetch has spent blocked
system.cpu.fetch.MiscStallCycles 148 # Number of cycles fetch has spent waiting on interrupts, or bad addresses, or out of MSHRs
system.cpu.fetch.PendingTrapStallCycles 4171 # Number of stall cycles due to pending traps
system.cpu.fetch.CacheLines 398172437 # Number of cache lines fetched
system.cpu.fetch.IcacheSquashes 11167265 # Number of outstanding Icache misses that were squashed
system.cpu.fetch.rateDist::samples 1286425438 # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::mean 2.606187 # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::stdev 3.132190 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.fetch.rateDist::0 641043996 49.83% 49.83% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::1 57060222 4.44% 54.27% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::2 45200815 3.51% 57.78% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::3 74446189 5.79% 63.57% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::4 134854552 10.48% 74.05% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::5 43347618 3.37% 77.42% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::6 44933428 3.49% 80.91% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::7 8201322 0.64% 81.55% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::8 237337296 18.45% 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.fetch.rateDist::total 1286425438 # Number of instructions fetched each cycle (Total)
system.cpu.fetch.branchRate 0.312723 # Number of branch fetches per cycle
system.cpu.fetch.rate 2.605921 # Number of inst fetches per cycle
system.cpu.decode.IdleCycles 450744873 # Number of cycles decode is idle
system.cpu.decode.BlockedCycles 71473924 # Number of cycles decode is blocked
system.cpu.decode.RunCycles 619092915 # Number of cycles decode is running
system.cpu.decode.UnblockCycles 8779214 # Number of cycles decode is unblocking
system.cpu.decode.SquashCycles 136334512 # Number of cycles decode is squashing
system.cpu.decode.BranchResolved 30672233 # Number of times decode resolved a branch
system.cpu.decode.BranchMispred 12086 # Number of times decode detected a branch misprediction
system.cpu.decode.DecodedInsts 3254497888 # Number of instructions handled by decode
system.cpu.decode.SquashedInsts 45897 # Number of squashed instructions handled by decode
system.cpu.rename.SquashCycles 136334512 # Number of cycles rename is squashing
system.cpu.rename.IdleCycles 481076883 # Number of cycles rename is idle
system.cpu.rename.BlockCycles 28014325 # Number of cycles rename is blocking
system.cpu.rename.serializeStallCycles 24661 # count of cycles rename stalled for serializing inst
system.cpu.rename.RunCycles 596193290 # Number of cycles rename is running
system.cpu.rename.UnblockCycles 44781767 # Number of cycles rename is unblocking
system.cpu.rename.RenamedInsts 3152490171 # Number of instructions processed by rename
system.cpu.rename.ROBFullEvents 251 # Number of times rename has blocked due to ROB full
system.cpu.rename.IQFullEvents 750331 # Number of times rename has blocked due to IQ full
system.cpu.rename.LSQFullEvents 37577847 # Number of times rename has blocked due to LSQ full
system.cpu.rename.RenamedOperands 2105819344 # Number of destination operands rename has renamed
system.cpu.rename.RenameLookups 3700266531 # Number of register rename lookups that rename has made
system.cpu.rename.int_rename_lookups 3588526705 # Number of integer rename lookups
system.cpu.rename.fp_rename_lookups 111739826 # 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 1384969070 # Number of HB maps that are committed
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.rename.UndoneMaps 720850274 # Number of HB maps that are undone due to squashing
system.cpu.rename.serializingInsts 2943 # count of serializing insts renamed
system.cpu.rename.tempSerializingInsts 84 # count of temporary serializing insts renamed
system.cpu.rename.skidInsts 124041279 # count of insts added to the skid buffer
system.cpu.memDep0.insertedLoads 733340932 # Number of loads inserted to the mem dependence unit.
system.cpu.memDep0.insertedStores 346031420 # Number of stores inserted to the mem dependence unit.
system.cpu.memDep0.conflictingLoads 95137569 # Number of conflicting loads.
system.cpu.memDep0.conflictingStores 27633179 # Number of conflicting stores.
system.cpu.iq.iqInstsAdded 2644257175 # Number of instructions added to the IQ (excludes non-spec)
system.cpu.iq.iqNonSpecInstsAdded 78 # Number of non-speculative instructions added to the IQ
system.cpu.iq.iqInstsIssued 2155824179 # Number of instructions issued
system.cpu.iq.iqSquashedInstsIssued 16126742 # Number of squashed instructions issued
system.cpu.iq.iqSquashedInstsExamined 820828364 # Number of squashed instructions iterated over during squash; mainly for profiling
system.cpu.iq.iqSquashedOperandsExamined 783816601 # Number of squashed operands that are examined and possibly removed from graph
system.cpu.iq.iqSquashedNonSpecRemoved 39 # Number of squashed non-spec instructions that were removed
system.cpu.iq.issued_per_cycle::samples 1286425438 # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::mean 1.675825 # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::stdev 1.770169 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iq.issued_per_cycle::0 467246309 36.32% 36.32% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::1 226022267 17.57% 53.89% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::2 245197843 19.06% 72.95% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::3 131574377 10.23% 83.18% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::4 102243605 7.95% 91.13% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::5 70385882 5.47% 96.60% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::6 25434522 1.98% 98.58% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::7 15392931 1.20% 99.77% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::8 2927702 0.23% 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iq.issued_per_cycle::total 1286425438 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iq.fu_full::IntAlu 16153 0.06% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::IntMult 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::IntDiv 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatAdd 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatCmp 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatCvt 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatMult 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatDiv 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatSqrt 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdAdd 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdAddAcc 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdAlu 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdCmp 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdCvt 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdMisc 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdMult 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdMultAcc 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdShift 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdShiftAcc 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdSqrt 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatAdd 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatAlu 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatCmp 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatCvt 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatDiv 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatMisc 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatMult 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatMultAcc 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatSqrt 0 0.00% 0.06% # attempts to use FU when none available
system.cpu.iq.fu_full::MemRead 21369886 75.29% 75.34% # attempts to use FU when none available
system.cpu.iq.fu_full::MemWrite 6999064 24.66% 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 2752 0.00% 0.00% # Type of FU issued
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iq.FU_type_0::IntAlu 1238199555 57.44% 57.44% # Type of FU issued
system.cpu.iq.FU_type_0::IntMult 16604 0.00% 57.44% # Type of FU issued
system.cpu.iq.FU_type_0::IntDiv 0 0.00% 57.44% # Type of FU issued
system.cpu.iq.FU_type_0::FloatAdd 27850923 1.29% 58.73% # Type of FU issued
system.cpu.iq.FU_type_0::FloatCmp 8254691 0.38% 59.11% # Type of FU issued
system.cpu.iq.FU_type_0::FloatCvt 7204648 0.33% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::FloatMult 4 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::FloatDiv 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::FloatSqrt 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdAdd 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdAddAcc 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdAlu 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdCmp 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdCvt 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdMisc 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdMult 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdMultAcc 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdShift 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdShiftAcc 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdSqrt 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatAdd 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatAlu 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatCmp 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatCvt 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatDiv 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatMisc 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatMult 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatMultAcc 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatSqrt 0 0.00% 59.44% # Type of FU issued
system.cpu.iq.FU_type_0::MemRead 584881936 27.13% 86.58% # Type of FU issued
system.cpu.iq.FU_type_0::MemWrite 289413066 13.42% 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iq.FU_type_0::total 2155824179 # Type of FU issued
system.cpu.iq.rate 1.675654 # Inst issue rate
system.cpu.iq.fu_busy_cnt 28385103 # FU busy when requested
system.cpu.iq.fu_busy_rate 0.013167 # FU busy rate (busy events/executed inst)
system.cpu.iq.int_inst_queue_reads 5494149121 # Number of integer instruction queue reads
system.cpu.iq.int_inst_queue_writes 3387002536 # Number of integer instruction queue writes
system.cpu.iq.int_inst_queue_wakeup_accesses 1990375209 # Number of integer instruction queue wakeup accesses
system.cpu.iq.fp_inst_queue_reads 148436520 # Number of floating instruction queue reads
system.cpu.iq.fp_inst_queue_writes 78085554 # Number of floating instruction queue writes
system.cpu.iq.fp_inst_queue_wakeup_accesses 72618270 # Number of floating instruction queue wakeup accesses
system.cpu.iq.int_alu_accesses 2108584760 # Number of integer alu accesses
system.cpu.iq.fp_alu_accesses 75621770 # Number of floating point alu accesses
system.cpu.iew.lsq.thread0.forwLoads 67562501 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iew.lsq.thread0.squashedLoads 222270906 # Number of loads squashed
system.cpu.iew.lsq.thread0.ignoredResponses 2427 # Number of memory responses ignored because the instruction is squashed
system.cpu.iew.lsq.thread0.memOrderViolation 2537 # Number of memory ordering violations
system.cpu.iew.lsq.thread0.squashedStores 135236524 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iew.lsq.thread0.rescheduledLoads 5770 # Number of loads that were rescheduled
system.cpu.iew.lsq.thread0.cacheBlocked 18 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iew.iewSquashCycles 136334512 # Number of cycles IEW is squashing
system.cpu.iew.iewBlockCycles 3822943 # Number of cycles IEW is blocking
system.cpu.iew.iewUnblockCycles 203706 # Number of cycles IEW is unblocking
system.cpu.iew.iewDispatchedInsts 3007852435 # Number of instructions dispatched to IQ
system.cpu.iew.iewDispSquashedInsts 2742591 # Number of squashed instructions skipped by dispatch
system.cpu.iew.iewDispLoadInsts 733340932 # Number of dispatched load instructions
system.cpu.iew.iewDispStoreInsts 346031420 # Number of dispatched store instructions
system.cpu.iew.iewDispNonSpecInsts 78 # Number of dispatched non-speculative instructions
system.cpu.iew.iewIQFullEvents 131030 # Number of times the IQ has become full, causing a stall
system.cpu.iew.iewLSQFullEvents 4921 # Number of times the LSQ has become full, causing a stall
system.cpu.iew.memOrderViolationEvents 2537 # Number of memory order violations
system.cpu.iew.predictedTakenIncorrect 30744167 # Number of branches that were predicted taken incorrectly
system.cpu.iew.predictedNotTakenIncorrect 897447 # Number of branches that were predicted not taken incorrectly
system.cpu.iew.branchMispredicts 31641614 # Number of branch mispredicts detected at execute
system.cpu.iew.iewExecutedInsts 2065462954 # Number of executed instructions
system.cpu.iew.iewExecLoadInsts 520628814 # Number of load instructions executed
system.cpu.iew.iewExecSquashedInsts 90361225 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iew.exec_nop 363595182 # number of nop insts executed
system.cpu.iew.exec_refs 804485830 # number of memory reference insts executed
system.cpu.iew.exec_branches 279503743 # Number of branches executed
system.cpu.iew.exec_stores 283857016 # Number of stores executed
system.cpu.iew.exec_rate 1.605419 # Inst execution rate
system.cpu.iew.wb_sent 2064970542 # cumulative count of insts sent to commit
system.cpu.iew.wb_count 2062993479 # cumulative count of insts written-back
system.cpu.iew.wb_producers 1176781433 # num instructions producing a value
system.cpu.iew.wb_consumers 1743261069 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iew.wb_rate 1.603500 # insts written-back per cycle
system.cpu.iew.wb_fanout 0.675046 # 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 2008987604 # The number of committed instructions
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.commit.commitSquashedInsts 982155641 # 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 39 # 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 28911563 # The number of times a branch was mispredicted
system.cpu.commit.committed_per_cycle::samples 1150090926 # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::mean 1.746808 # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::stdev 2.513435 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.commit.committed_per_cycle::0 542926028 47.21% 47.21% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::1 216885753 18.86% 66.07% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::2 119710361 10.41% 76.47% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::3 61150951 5.32% 81.79% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::4 44124600 3.84% 85.63% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::5 24943285 2.17% 87.80% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::6 19289585 1.68% 89.47% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::7 16206963 1.41% 90.88% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::8 104853400 9.12% 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.commit.committed_per_cycle::total 1150090926 # 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 2008987604 # Number of instructions committed
system.cpu.commit.swp_count 0 # Number of s/w prefetches committed
system.cpu.commit.refs 721864922 # Number of memory references committed
system.cpu.commit.loads 511070026 # Number of loads committed
system.cpu.commit.membars 0 # Number of memory barriers committed
system.cpu.commit.branches 266706457 # Number of branches committed
system.cpu.commit.fp_insts 71824891 # Number of committed floating point instructions.
system.cpu.commit.int_insts 1778941351 # Number of committed integer instructions.
system.cpu.commit.function_calls 39955347 # Number of function calls committed.
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.commit.bw_lim_events 104853400 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.rob.rob_reads 4030744361 # The number of ROB reads
system.cpu.rob.rob_writes 6118806810 # The number of ROB writes
system.cpu.timesIdled 3658 # Number of times that the entire CPU went into an idle state and unscheduled itself
system.cpu.idleCycles 131218 # 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 1823043370 # Number of Instructions Simulated
system.cpu.committedInsts_total 1823043370 # Number of Instructions Simulated
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.cpi 0.705719 # CPI: Cycles Per Instruction
system.cpu.cpi_total 0.705719 # CPI: Total CPI of All Threads
system.cpu.ipc 1.416994 # IPC: Instructions Per Cycle
system.cpu.ipc_total 1.416994 # IPC: Total IPC of All Threads
system.cpu.int_regfile_reads 2630024814 # number of integer regfile reads
system.cpu.int_regfile_writes 1492719850 # number of integer regfile writes
system.cpu.fp_regfile_reads 77822488 # number of floating regfile reads
system.cpu.fp_regfile_writes 52815654 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.icache.replacements 8249 # number of replacements
system.cpu.icache.tagsinuse 1648.525353 # Cycle average of tags in use
system.cpu.icache.total_refs 398161333 # Total number of references to valid blocks.
system.cpu.icache.sampled_refs 9955 # Sample count of references to valid blocks.
system.cpu.icache.avg_refs 39996.115821 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.icache.occ_blocks::0 1648.525353 # Average occupied blocks per context
system.cpu.icache.occ_percent::0 0.804944 # Average percentage of cache occupancy
system.cpu.icache.ReadReq_hits 398161333 # number of ReadReq hits
system.cpu.icache.demand_hits 398161333 # number of demand (read+write) hits
system.cpu.icache.overall_hits 398161333 # number of overall hits
system.cpu.icache.ReadReq_misses 11104 # number of ReadReq misses
system.cpu.icache.demand_misses 11104 # number of demand (read+write) misses
system.cpu.icache.overall_misses 11104 # number of overall misses
system.cpu.icache.ReadReq_miss_latency 182797500 # number of ReadReq miss cycles
system.cpu.icache.demand_miss_latency 182797500 # number of demand (read+write) miss cycles
system.cpu.icache.overall_miss_latency 182797500 # number of overall miss cycles
system.cpu.icache.ReadReq_accesses 398172437 # number of ReadReq accesses(hits+misses)
system.cpu.icache.demand_accesses 398172437 # number of demand (read+write) accesses
system.cpu.icache.overall_accesses 398172437 # number of overall (read+write) accesses
system.cpu.icache.ReadReq_miss_rate 0.000028 # miss rate for ReadReq accesses
system.cpu.icache.demand_miss_rate 0.000028 # miss rate for demand accesses
system.cpu.icache.overall_miss_rate 0.000028 # miss rate for overall accesses
system.cpu.icache.ReadReq_avg_miss_latency 16462.310879 # average ReadReq miss latency
system.cpu.icache.demand_avg_miss_latency 16462.310879 # average overall miss latency
system.cpu.icache.overall_avg_miss_latency 16462.310879 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.icache.ReadReq_mshr_hits 1148 # number of ReadReq MSHR hits
system.cpu.icache.demand_mshr_hits 1148 # number of demand (read+write) MSHR hits
system.cpu.icache.overall_mshr_hits 1148 # number of overall MSHR hits
system.cpu.icache.ReadReq_mshr_misses 9956 # number of ReadReq MSHR misses
system.cpu.icache.demand_mshr_misses 9956 # number of demand (read+write) MSHR misses
system.cpu.icache.overall_mshr_misses 9956 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.icache.ReadReq_mshr_miss_latency 119908500 # number of ReadReq MSHR miss cycles
system.cpu.icache.demand_mshr_miss_latency 119908500 # number of demand (read+write) MSHR miss cycles
system.cpu.icache.overall_mshr_miss_latency 119908500 # 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.000025 # mshr miss rate for ReadReq accesses
system.cpu.icache.demand_mshr_miss_rate 0.000025 # mshr miss rate for demand accesses
system.cpu.icache.overall_mshr_miss_rate 0.000025 # mshr miss rate for overall accesses
system.cpu.icache.ReadReq_avg_mshr_miss_latency 12043.842909 # average ReadReq mshr miss latency
system.cpu.icache.demand_avg_mshr_miss_latency 12043.842909 # average overall mshr miss latency
system.cpu.icache.overall_avg_mshr_miss_latency 12043.842909 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.replacements 1526943 # number of replacements
system.cpu.dcache.tagsinuse 4095.108553 # Cycle average of tags in use
system.cpu.dcache.total_refs 660714952 # Total number of references to valid blocks.
system.cpu.dcache.sampled_refs 1531039 # Sample count of references to valid blocks.
system.cpu.dcache.avg_refs 431.546781 # Average number of references to valid blocks.
system.cpu.dcache.warmup_cycle 256550000 # Cycle when the warmup percentage was hit.
system.cpu.dcache.occ_blocks::0 4095.108553 # Average occupied blocks per context
system.cpu.dcache.occ_percent::0 0.999782 # Average percentage of cache occupancy
system.cpu.dcache.ReadReq_hits 450471495 # number of ReadReq hits
system.cpu.dcache.WriteReq_hits 210243448 # number of WriteReq hits
system.cpu.dcache.LoadLockedReq_hits 9 # number of LoadLockedReq hits
system.cpu.dcache.demand_hits 660714943 # number of demand (read+write) hits
system.cpu.dcache.overall_hits 660714943 # number of overall hits
system.cpu.dcache.ReadReq_misses 1926978 # number of ReadReq misses
system.cpu.dcache.WriteReq_misses 551448 # number of WriteReq misses
system.cpu.dcache.LoadLockedReq_misses 3 # number of LoadLockedReq misses
system.cpu.dcache.demand_misses 2478426 # number of demand (read+write) misses
system.cpu.dcache.overall_misses 2478426 # number of overall misses
system.cpu.dcache.ReadReq_miss_latency 71403545500 # number of ReadReq miss cycles
system.cpu.dcache.WriteReq_miss_latency 20877102491 # number of WriteReq miss cycles
system.cpu.dcache.LoadLockedReq_miss_latency 92500 # number of LoadLockedReq miss cycles
system.cpu.dcache.demand_miss_latency 92280647991 # number of demand (read+write) miss cycles
system.cpu.dcache.overall_miss_latency 92280647991 # number of overall miss cycles
system.cpu.dcache.ReadReq_accesses 452398473 # 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 210794896 # number of WriteReq accesses(hits+misses)
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.LoadLockedReq_accesses 12 # number of LoadLockedReq accesses(hits+misses)
system.cpu.dcache.demand_accesses 663193369 # number of demand (read+write) accesses
system.cpu.dcache.overall_accesses 663193369 # number of overall (read+write) accesses
system.cpu.dcache.ReadReq_miss_rate 0.004259 # miss rate for ReadReq accesses
system.cpu.dcache.WriteReq_miss_rate 0.002616 # miss rate for WriteReq accesses
system.cpu.dcache.LoadLockedReq_miss_rate 0.250000 # miss rate for LoadLockedReq accesses
system.cpu.dcache.demand_miss_rate 0.003737 # miss rate for demand accesses
system.cpu.dcache.overall_miss_rate 0.003737 # miss rate for overall accesses
system.cpu.dcache.ReadReq_avg_miss_latency 37054.676026 # average ReadReq miss latency
system.cpu.dcache.WriteReq_avg_miss_latency 37858.696543 # average WriteReq miss latency
system.cpu.dcache.LoadLockedReq_avg_miss_latency 30833.333333 # average LoadLockedReq miss latency
system.cpu.dcache.demand_avg_miss_latency 37233.570012 # average overall miss latency
system.cpu.dcache.overall_avg_miss_latency 37233.570012 # average overall miss latency
system.cpu.dcache.blocked_cycles::no_mshrs 73500 # number of cycles access was blocked
system.cpu.dcache.blocked_cycles::no_targets 17000 # number of cycles access was blocked
system.cpu.dcache.blocked::no_mshrs 13 # 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 1 # 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.avg_blocked_cycles::no_mshrs 5653.846154 # average number of cycles each access was blocked
system.cpu.dcache.avg_blocked_cycles::no_targets 17000 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.writebacks 107355 # number of writebacks
system.cpu.dcache.ReadReq_mshr_hits 467583 # number of ReadReq MSHR hits
system.cpu.dcache.WriteReq_mshr_hits 479805 # number of WriteReq MSHR hits
system.cpu.dcache.LoadLockedReq_mshr_hits 2 # number of LoadLockedReq MSHR hits
system.cpu.dcache.demand_mshr_hits 947388 # number of demand (read+write) MSHR hits
system.cpu.dcache.overall_mshr_hits 947388 # number of overall MSHR hits
system.cpu.dcache.ReadReq_mshr_misses 1459395 # number of ReadReq MSHR misses
system.cpu.dcache.WriteReq_mshr_misses 71643 # number of WriteReq MSHR misses
system.cpu.dcache.LoadLockedReq_mshr_misses 1 # number of LoadLockedReq MSHR misses
system.cpu.dcache.demand_mshr_misses 1531038 # number of demand (read+write) MSHR misses
system.cpu.dcache.overall_mshr_misses 1531038 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.ReadReq_mshr_miss_latency 49913534500 # number of ReadReq MSHR miss cycles
system.cpu.dcache.WriteReq_mshr_miss_latency 2493312500 # number of WriteReq MSHR miss cycles
system.cpu.dcache.LoadLockedReq_mshr_miss_latency 35000 # number of LoadLockedReq MSHR miss cycles
system.cpu.dcache.demand_mshr_miss_latency 52406847000 # number of demand (read+write) MSHR miss cycles
system.cpu.dcache.overall_mshr_miss_latency 52406847000 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.ReadReq_mshr_miss_rate 0.003226 # mshr miss rate for ReadReq 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.dcache.WriteReq_mshr_miss_rate 0.000340 # mshr miss rate for WriteReq accesses
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.LoadLockedReq_mshr_miss_rate 0.083333 # mshr miss rate for LoadLockedReq accesses
system.cpu.dcache.demand_mshr_miss_rate 0.002309 # mshr miss rate for demand accesses
system.cpu.dcache.overall_mshr_miss_rate 0.002309 # mshr miss rate for overall accesses
system.cpu.dcache.ReadReq_avg_mshr_miss_latency 34201.524947 # average ReadReq mshr miss latency
system.cpu.dcache.WriteReq_avg_mshr_miss_latency 34801.899697 # average WriteReq mshr miss latency
system.cpu.dcache.LoadLockedReq_avg_mshr_miss_latency 35000 # average LoadLockedReq mshr miss latency
system.cpu.dcache.demand_avg_mshr_miss_latency 34229.618729 # average overall mshr miss latency
system.cpu.dcache.overall_avg_mshr_miss_latency 34229.618729 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.l2cache.replacements 1480567 # number of replacements
system.cpu.l2cache.tagsinuse 31934.538641 # Cycle average of tags in use
system.cpu.l2cache.total_refs 62997 # Total number of references to valid blocks.
system.cpu.l2cache.sampled_refs 1513254 # Sample count of references to valid blocks.
system.cpu.l2cache.avg_refs 0.041630 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.l2cache.occ_blocks::0 28868.809118 # Average occupied blocks per context
system.cpu.l2cache.occ_blocks::1 3065.729523 # Average occupied blocks per context
system.cpu.l2cache.occ_percent::0 0.881006 # Average percentage of cache occupancy
system.cpu.l2cache.occ_percent::1 0.093559 # Average percentage of cache occupancy
system.cpu.l2cache.ReadReq_hits 55380 # number of ReadReq hits
system.cpu.l2cache.Writeback_hits 107355 # number of Writeback hits
system.cpu.l2cache.ReadExReq_hits 4788 # number of ReadExReq hits
system.cpu.l2cache.demand_hits 60168 # number of demand (read+write) hits
system.cpu.l2cache.overall_hits 60168 # number of overall hits
system.cpu.l2cache.ReadReq_misses 1413972 # number of ReadReq misses
system.cpu.l2cache.ReadExReq_misses 66855 # number of ReadExReq misses
system.cpu.l2cache.demand_misses 1480827 # number of demand (read+write) misses
system.cpu.l2cache.overall_misses 1480827 # number of overall misses
system.cpu.l2cache.ReadReq_miss_latency 48486615500 # number of ReadReq miss cycles
system.cpu.l2cache.ReadExReq_miss_latency 2348963000 # number of ReadExReq miss cycles
system.cpu.l2cache.demand_miss_latency 50835578500 # number of demand (read+write) miss cycles
system.cpu.l2cache.overall_miss_latency 50835578500 # number of overall miss cycles
system.cpu.l2cache.ReadReq_accesses 1469352 # number of ReadReq accesses(hits+misses)
system.cpu.l2cache.Writeback_accesses 107355 # number of Writeback accesses(hits+misses)
system.cpu.l2cache.ReadExReq_accesses 71643 # number of ReadExReq accesses(hits+misses)
system.cpu.l2cache.demand_accesses 1540995 # number of demand (read+write) accesses
system.cpu.l2cache.overall_accesses 1540995 # number of overall (read+write) accesses
system.cpu.l2cache.ReadReq_miss_rate 0.962310 # miss rate for ReadReq accesses
system.cpu.l2cache.ReadExReq_miss_rate 0.933169 # miss rate for ReadExReq accesses
system.cpu.l2cache.demand_miss_rate 0.960955 # miss rate for demand accesses
system.cpu.l2cache.overall_miss_rate 0.960955 # miss rate for overall accesses
system.cpu.l2cache.ReadReq_avg_miss_latency 34291.071888 # average ReadReq miss latency
system.cpu.l2cache.ReadExReq_avg_miss_latency 35135.188094 # average ReadExReq miss latency
system.cpu.l2cache.demand_avg_miss_latency 34329.181262 # average overall miss latency
system.cpu.l2cache.overall_avg_miss_latency 34329.181262 # average overall miss latency
system.cpu.l2cache.blocked_cycles::no_mshrs 33000 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.l2cache.blocked::no_mshrs 6 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.l2cache.avg_blocked_cycles::no_mshrs 5500 # 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
system.cpu.l2cache.writebacks 66898 # number of writebacks
system.cpu.l2cache.demand_mshr_hits 0 # number of demand (read+write) MSHR hits
tests: perlbmk now works. Commit stats and assume the're right. Kevin fixed how O3 handles syscalls that change NextPC (longjump).
2008-09-28 23:15:50 +02:00
system.cpu.l2cache.overall_mshr_hits 0 # number of overall MSHR hits
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.l2cache.ReadReq_mshr_misses 1413972 # number of ReadReq MSHR misses
system.cpu.l2cache.ReadExReq_mshr_misses 66855 # number of ReadExReq MSHR misses
system.cpu.l2cache.demand_mshr_misses 1480827 # number of demand (read+write) MSHR misses
system.cpu.l2cache.overall_mshr_misses 1480827 # number of overall MSHR misses
tests: perlbmk now works. Commit stats and assume the're right. Kevin fixed how O3 handles syscalls that change NextPC (longjump).
2008-09-28 23:15:50 +02:00
system.cpu.l2cache.overall_mshr_uncacheable_misses 0 # number of overall MSHR uncacheable misses
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.l2cache.ReadReq_mshr_miss_latency 43834352500 # number of ReadReq MSHR miss cycles
system.cpu.l2cache.ReadExReq_mshr_miss_latency 2147649000 # number of ReadExReq MSHR miss cycles
system.cpu.l2cache.demand_mshr_miss_latency 45982001500 # number of demand (read+write) MSHR miss cycles
system.cpu.l2cache.overall_mshr_miss_latency 45982001500 # 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 fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.l2cache.ReadReq_mshr_miss_rate 0.962310 # mshr miss rate for ReadReq accesses
system.cpu.l2cache.ReadExReq_mshr_miss_rate 0.933169 # mshr miss rate for ReadExReq accesses
system.cpu.l2cache.demand_mshr_miss_rate 0.960955 # mshr miss rate for demand accesses
system.cpu.l2cache.overall_mshr_miss_rate 0.960955 # mshr miss rate for overall accesses
system.cpu.l2cache.ReadReq_avg_mshr_miss_latency 31000.863171 # average ReadReq mshr miss latency
system.cpu.l2cache.ReadExReq_avg_mshr_miss_latency 32123.984743 # average ReadExReq mshr miss latency
system.cpu.l2cache.demand_avg_mshr_miss_latency 31051.568819 # average overall mshr miss latency
system.cpu.l2cache.overall_avg_mshr_miss_latency 31051.568819 # 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
tests: perlbmk now works. Commit stats and assume the're right. Kevin fixed how O3 handles syscalls that change NextPC (longjump).
2008-09-28 23:15:50 +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
tests: perlbmk now works. Commit stats and assume the're right. Kevin fixed how O3 handles syscalls that change NextPC (longjump).
2008-09-28 23:15:50 +02:00
---------- End Simulation Statistics ----------
Reference in a new issue Copy permalink