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

515 lines
57 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.029167 # Number of seconds simulated
sim_ticks 29167093500 # 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 new ordering fix.
2011-09-13 18:58:09 +02:00
host_inst_rate 127298 # Simulator instruction rate (inst/s)
host_tick_rate 44106983 # Simulator tick rate (ticks/s)
host_mem_usage 209296 # Number of bytes of host memory used
host_seconds 661.28 # 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 84179709 # 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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dtb.read_hits 25236325 # DTB read hits
system.cpu.dtb.read_misses 540509 # 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 25776834 # DTB read accesses
system.cpu.dtb.write_hits 7362909 # DTB write hits
system.cpu.dtb.write_misses 1032 # DTB write misses
system.cpu.dtb.write_acv 0 # DTB write access violations
system.cpu.dtb.write_accesses 7363941 # DTB write accesses
system.cpu.dtb.data_hits 32599234 # DTB hits
system.cpu.dtb.data_misses 541541 # DTB misses
system.cpu.dtb.data_acv 0 # DTB access violations
system.cpu.dtb.data_accesses 33140775 # DTB accesses
system.cpu.itb.fetch_hits 18604047 # ITB hits
system.cpu.itb.fetch_misses 85 # 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 18604132 # 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 389 # Number of system calls
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.numCycles 58334188 # 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 18443606 # Number of BP lookups
system.cpu.BPredUnit.condPredicted 13550904 # Number of conditional branches predicted
system.cpu.BPredUnit.condIncorrect 1909309 # Number of conditional branches incorrect
system.cpu.BPredUnit.BTBLookups 15151906 # Number of BTB lookups
system.cpu.BPredUnit.BTBHits 11744171 # 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 1797123 # Number of times the RAS was used to get a target.
system.cpu.BPredUnit.RASInCorrect 2508 # Number of incorrect RAS predictions.
system.cpu.fetch.icacheStallCycles 19753130 # Number of cycles fetch is stalled on an Icache miss
system.cpu.fetch.Insts 155901269 # Number of instructions fetch has processed
system.cpu.fetch.Branches 18443606 # Number of branches that fetch encountered
system.cpu.fetch.predictedBranches 13541294 # Number of branches that fetch has predicted taken
system.cpu.fetch.Cycles 28873870 # Number of cycles fetch has run and was not squashing or blocked
system.cpu.fetch.SquashCycles 8029527 # Number of cycles fetch has spent squashing
system.cpu.fetch.BlockedCycles 3519156 # Number of cycles fetch has spent blocked
system.cpu.fetch.MiscStallCycles 49 # Number of cycles fetch has spent waiting on interrupts, or bad addresses, or out of MSHRs
system.cpu.fetch.PendingTrapStallCycles 1819 # Number of stall cycles due to pending traps
system.cpu.fetch.CacheLines 18604047 # Number of cache lines fetched
system.cpu.fetch.IcacheSquashes 633220 # Number of outstanding Icache misses that were squashed
system.cpu.fetch.rateDist::samples 58241050 # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::mean 2.676828 # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::stdev 3.252315 # 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 29367180 50.42% 50.42% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::1 2937608 5.04% 55.47% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::2 2015194 3.46% 58.93% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::3 3338566 5.73% 64.66% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::4 4094138 7.03% 71.69% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::5 1423310 2.44% 74.13% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::6 1755062 3.01% 77.15% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::7 1585835 2.72% 79.87% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::8 11724157 20.13% 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 58241050 # Number of instructions fetched each cycle (Total)
system.cpu.fetch.branchRate 0.316171 # Number of branch fetches per cycle
system.cpu.fetch.rate 2.672554 # Number of inst fetches per cycle
system.cpu.decode.IdleCycles 21649179 # Number of cycles decode is idle
system.cpu.decode.BlockedCycles 2708949 # Number of cycles decode is blocked
system.cpu.decode.RunCycles 27144653 # Number of cycles decode is running
system.cpu.decode.UnblockCycles 658698 # Number of cycles decode is unblocking
system.cpu.decode.SquashCycles 6079571 # Number of cycles decode is squashing
system.cpu.decode.BranchResolved 2969190 # Number of times decode resolved a branch
system.cpu.decode.BranchMispred 13806 # Number of times decode detected a branch misprediction
system.cpu.decode.DecodedInsts 150046107 # Number of instructions handled by decode
system.cpu.decode.SquashedInsts 43597 # Number of squashed instructions handled by decode
system.cpu.rename.SquashCycles 6079571 # Number of cycles rename is squashing
system.cpu.rename.IdleCycles 23241789 # Number of cycles rename is idle
system.cpu.rename.BlockCycles 566661 # Number of cycles rename is blocking
system.cpu.rename.serializeStallCycles 6095 # count of cycles rename stalled for serializing inst
system.cpu.rename.RunCycles 26202396 # Number of cycles rename is running
system.cpu.rename.UnblockCycles 2144538 # Number of cycles rename is unblocking
system.cpu.rename.RenamedInsts 144061667 # Number of instructions processed by rename
system.cpu.rename.ROBFullEvents 3 # Number of times rename has blocked due to ROB full
system.cpu.rename.IQFullEvents 244284 # Number of times rename has blocked due to IQ full
system.cpu.rename.LSQFullEvents 1605069 # Number of times rename has blocked due to LSQ full
system.cpu.rename.RenamedOperands 105522995 # Number of destination operands rename has renamed
system.cpu.rename.RenameLookups 186327738 # Number of register rename lookups that rename has made
system.cpu.rename.int_rename_lookups 175726328 # Number of integer rename lookups
system.cpu.rename.fp_rename_lookups 10601410 # 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 68427361 # 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 37095634 # Number of HB maps that are undone due to squashing
system.cpu.rename.serializingInsts 535 # count of serializing insts renamed
system.cpu.rename.tempSerializingInsts 531 # count of temporary serializing insts renamed
system.cpu.rename.skidInsts 6071657 # count of insts added to the skid buffer
system.cpu.memDep0.insertedLoads 29750182 # Number of loads inserted to the mem dependence unit.
system.cpu.memDep0.insertedStores 9383371 # Number of stores inserted to the mem dependence unit.
system.cpu.memDep0.conflictingLoads 2457988 # Number of conflicting loads.
system.cpu.memDep0.conflictingStores 836885 # Number of conflicting stores.
system.cpu.iq.iqInstsAdded 120824169 # Number of instructions added to the IQ (excludes non-spec)
system.cpu.iq.iqNonSpecInstsAdded 510 # Number of non-speculative instructions added to the IQ
system.cpu.iq.iqInstsIssued 104934850 # Number of instructions issued
system.cpu.iq.iqSquashedInstsIssued 288533 # Number of squashed instructions issued
system.cpu.iq.iqSquashedInstsExamined 35688110 # Number of squashed instructions iterated over during squash; mainly for profiling
system.cpu.iq.iqSquashedOperandsExamined 27652526 # Number of squashed operands that are examined and possibly removed from graph
system.cpu.iq.iqSquashedNonSpecRemoved 121 # Number of squashed non-spec instructions that were removed
system.cpu.iq.issued_per_cycle::samples 58241050 # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::mean 1.801733 # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::stdev 1.850509 # 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 19806248 34.01% 34.01% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::1 11039636 18.96% 52.96% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::2 9348946 16.05% 69.01% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::3 6752104 11.59% 80.61% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::4 5521673 9.48% 90.09% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::5 2974014 5.11% 95.20% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::6 1775531 3.05% 98.24% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::7 852122 1.46% 99.71% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::8 170776 0.29% 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 58241050 # 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 161609 9.97% 9.97% # attempts to use FU when none available
system.cpu.iq.fu_full::IntMult 0 0.00% 9.97% # attempts to use FU when none available
system.cpu.iq.fu_full::IntDiv 0 0.00% 9.97% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatAdd 218 0.01% 9.98% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatCmp 0 0.00% 9.98% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatCvt 6469 0.40% 10.38% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatMult 2295 0.14% 10.52% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatDiv 845619 52.17% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatSqrt 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdAdd 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdAddAcc 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdAlu 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdCmp 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdCvt 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdMisc 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdMult 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdMultAcc 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdShift 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdShiftAcc 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdSqrt 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatAdd 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatAlu 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatCmp 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatCvt 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatDiv 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatMisc 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatMult 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatMultAcc 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatSqrt 0 0.00% 62.69% # attempts to use FU when none available
system.cpu.iq.fu_full::MemRead 527151 32.52% 95.21% # attempts to use FU when none available
system.cpu.iq.fu_full::MemWrite 77634 4.79% 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 7 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 63561145 60.57% 60.57% # Type of FU issued
system.cpu.iq.FU_type_0::IntMult 485535 0.46% 61.03% # Type of FU issued
system.cpu.iq.FU_type_0::IntDiv 0 0.00% 61.03% # Type of FU issued
system.cpu.iq.FU_type_0::FloatAdd 2794061 2.66% 63.70% # Type of FU issued
system.cpu.iq.FU_type_0::FloatCmp 115045 0.11% 63.81% # Type of FU issued
system.cpu.iq.FU_type_0::FloatCvt 2411045 2.30% 66.10% # Type of FU issued
system.cpu.iq.FU_type_0::FloatMult 308682 0.29% 66.40% # Type of FU issued
system.cpu.iq.FU_type_0::FloatDiv 763571 0.73% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::FloatSqrt 318 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdAdd 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdAddAcc 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdAlu 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdCmp 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdCvt 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdMisc 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdMult 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdMultAcc 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdShift 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdShiftAcc 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdSqrt 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatAdd 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatAlu 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatCmp 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatCvt 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatDiv 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatMisc 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatMult 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatMultAcc 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatSqrt 0 0.00% 67.13% # Type of FU issued
system.cpu.iq.FU_type_0::MemRead 27006510 25.74% 92.86% # Type of FU issued
system.cpu.iq.FU_type_0::MemWrite 7488931 7.14% 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 104934850 # Type of FU issued
system.cpu.iq.rate 1.798857 # Inst issue rate
system.cpu.iq.fu_busy_cnt 1620995 # FU busy when requested
system.cpu.iq.fu_busy_rate 0.015448 # FU busy rate (busy events/executed inst)
system.cpu.iq.int_inst_queue_reads 254843963 # Number of integer instruction queue reads
system.cpu.iq.int_inst_queue_writes 146750024 # Number of integer instruction queue writes
system.cpu.iq.int_inst_queue_wakeup_accesses 92740043 # Number of integer instruction queue wakeup accesses
system.cpu.iq.fp_inst_queue_reads 15176315 # Number of floating instruction queue reads
system.cpu.iq.fp_inst_queue_writes 9791044 # Number of floating instruction queue writes
system.cpu.iq.fp_inst_queue_wakeup_accesses 7062550 # Number of floating instruction queue wakeup accesses
system.cpu.iq.int_alu_accesses 98540004 # Number of integer alu accesses
system.cpu.iq.fp_alu_accesses 8015834 # Number of floating point alu accesses
system.cpu.iew.lsq.thread0.forwLoads 1319105 # 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 9753984 # Number of loads squashed
system.cpu.iew.lsq.thread0.ignoredResponses 15279 # Number of memory responses ignored because the instruction is squashed
system.cpu.iew.lsq.thread0.memOrderViolation 28494 # Number of memory ordering violations
system.cpu.iew.lsq.thread0.squashedStores 2882268 # 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 10177 # Number of loads that were rescheduled
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.cacheBlocked 1 # Number of times an access to memory failed due to the cache being blocked
system.cpu.iew.iewIdleCycles 0 # Number of cycles IEW is idle
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.iewSquashCycles 6079571 # Number of cycles IEW is squashing
system.cpu.iew.iewBlockCycles 81043 # Number of cycles IEW is blocking
system.cpu.iew.iewUnblockCycles 15363 # Number of cycles IEW is unblocking
system.cpu.iew.iewDispatchedInsts 132624218 # Number of instructions dispatched to IQ
system.cpu.iew.iewDispSquashedInsts 876009 # Number of squashed instructions skipped by dispatch
system.cpu.iew.iewDispLoadInsts 29750182 # Number of dispatched load instructions
system.cpu.iew.iewDispStoreInsts 9383371 # Number of dispatched store instructions
system.cpu.iew.iewDispNonSpecInsts 510 # Number of dispatched non-speculative instructions
system.cpu.iew.iewIQFullEvents 184 # Number of times the IQ has become full, causing a stall
StoreSet: Update stats for store-set clearing
2011-08-19 22:08:08 +02:00
system.cpu.iew.iewLSQFullEvents 33 # Number of times the LSQ has become full, causing a stall
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.memOrderViolationEvents 28494 # Number of memory order violations
system.cpu.iew.predictedTakenIncorrect 1787084 # Number of branches that were predicted taken incorrectly
system.cpu.iew.predictedNotTakenIncorrect 342134 # Number of branches that were predicted not taken incorrectly
system.cpu.iew.branchMispredicts 2129218 # Number of branch mispredicts detected at execute
system.cpu.iew.iewExecutedInsts 102333218 # Number of executed instructions
system.cpu.iew.iewExecLoadInsts 25777384 # Number of load instructions executed
system.cpu.iew.iewExecSquashedInsts 2601632 # 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 11799539 # number of nop insts executed
system.cpu.iew.exec_refs 33141424 # number of memory reference insts executed
system.cpu.iew.exec_branches 12916232 # Number of branches executed
system.cpu.iew.exec_stores 7364040 # Number of stores executed
system.cpu.iew.exec_rate 1.754258 # Inst execution rate
system.cpu.iew.wb_sent 101006568 # cumulative count of insts sent to commit
system.cpu.iew.wb_count 99802593 # cumulative count of insts written-back
system.cpu.iew.wb_producers 67789343 # num instructions producing a value
system.cpu.iew.wb_consumers 93484829 # 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 1.710877 # insts written-back per cycle
system.cpu.iew.wb_fanout 0.725137 # 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 91903055 # The number of committed instructions
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.commit.commitSquashedInsts 40723267 # 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 389 # 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 1895854 # The number of times a branch was mispredicted
system.cpu.commit.committed_per_cycle::samples 52161479 # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::mean 1.761895 # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::stdev 2.510937 # 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 23655247 45.35% 45.35% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::1 11195713 21.46% 66.81% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::2 5070133 9.72% 76.53% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::3 2810925 5.39% 81.92% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::4 1675607 3.21% 85.13% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::5 1392452 2.67% 87.80% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::6 795157 1.52% 89.33% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::7 831289 1.59% 90.92% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::8 4734956 9.08% 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 52161479 # 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 91903055 # Number of instructions committed
system.cpu.commit.swp_count 0 # Number of s/w prefetches committed
system.cpu.commit.refs 26497301 # Number of memory references committed
system.cpu.commit.loads 19996198 # Number of loads committed
system.cpu.commit.membars 0 # Number of memory barriers committed
system.cpu.commit.branches 10240685 # Number of branches committed
system.cpu.commit.fp_insts 6862061 # Number of committed floating point instructions.
system.cpu.commit.int_insts 79581076 # Number of committed integer instructions.
system.cpu.commit.function_calls 1029620 # 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 4734956 # 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 180051805 # The number of ROB reads
system.cpu.rob.rob_writes 271380444 # The number of ROB writes
system.cpu.timesIdled 2277 # Number of times that the entire CPU went into an idle state and unscheduled itself
system.cpu.idleCycles 93138 # 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 84179709 # Number of Instructions Simulated
system.cpu.committedInsts_total 84179709 # Number of Instructions Simulated
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.cpi 0.692972 # CPI: Cycles Per Instruction
system.cpu.cpi_total 0.692972 # CPI: Total CPI of All Threads
system.cpu.ipc 1.443060 # IPC: Instructions Per Cycle
system.cpu.ipc_total 1.443060 # IPC: Total IPC of All Threads
system.cpu.int_regfile_reads 138495671 # number of integer regfile reads
system.cpu.int_regfile_writes 75435014 # number of integer regfile writes
system.cpu.fp_regfile_reads 6177236 # number of floating regfile reads
system.cpu.fp_regfile_writes 6044349 # number of floating regfile writes
system.cpu.misc_regfile_reads 715554 # number of misc regfile reads
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_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 8695 # number of replacements
system.cpu.icache.tagsinuse 1593.002324 # Cycle average of tags in use
system.cpu.icache.total_refs 18592194 # Total number of references to valid blocks.
system.cpu.icache.sampled_refs 10628 # Sample count of references to valid blocks.
system.cpu.icache.avg_refs 1749.359616 # 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 1593.002324 # Average occupied blocks per context
system.cpu.icache.occ_percent::0 0.777833 # Average percentage of cache occupancy
system.cpu.icache.ReadReq_hits 18592194 # number of ReadReq hits
system.cpu.icache.demand_hits 18592194 # number of demand (read+write) hits
system.cpu.icache.overall_hits 18592194 # number of overall hits
system.cpu.icache.ReadReq_misses 11853 # number of ReadReq misses
system.cpu.icache.demand_misses 11853 # number of demand (read+write) misses
system.cpu.icache.overall_misses 11853 # number of overall misses
system.cpu.icache.ReadReq_miss_latency 188036500 # number of ReadReq miss cycles
system.cpu.icache.demand_miss_latency 188036500 # number of demand (read+write) miss cycles
system.cpu.icache.overall_miss_latency 188036500 # number of overall miss cycles
system.cpu.icache.ReadReq_accesses 18604047 # number of ReadReq accesses(hits+misses)
system.cpu.icache.demand_accesses 18604047 # number of demand (read+write) accesses
system.cpu.icache.overall_accesses 18604047 # number of overall (read+write) accesses
system.cpu.icache.ReadReq_miss_rate 0.000637 # miss rate for ReadReq accesses
system.cpu.icache.demand_miss_rate 0.000637 # miss rate for demand accesses
system.cpu.icache.overall_miss_rate 0.000637 # miss rate for overall accesses
system.cpu.icache.ReadReq_avg_miss_latency 15864.042858 # average ReadReq miss latency
system.cpu.icache.demand_avg_miss_latency 15864.042858 # average overall miss latency
system.cpu.icache.overall_avg_miss_latency 15864.042858 # 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 1225 # number of ReadReq MSHR hits
system.cpu.icache.demand_mshr_hits 1225 # number of demand (read+write) MSHR hits
system.cpu.icache.overall_mshr_hits 1225 # number of overall MSHR hits
system.cpu.icache.ReadReq_mshr_misses 10628 # number of ReadReq MSHR misses
system.cpu.icache.demand_mshr_misses 10628 # number of demand (read+write) MSHR misses
system.cpu.icache.overall_mshr_misses 10628 # 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 124769000 # number of ReadReq MSHR miss cycles
system.cpu.icache.demand_mshr_miss_latency 124769000 # number of demand (read+write) MSHR miss cycles
system.cpu.icache.overall_mshr_miss_latency 124769000 # 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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.icache.ReadReq_mshr_miss_rate 0.000571 # mshr miss rate for ReadReq accesses
system.cpu.icache.demand_mshr_miss_rate 0.000571 # mshr miss rate for demand accesses
system.cpu.icache.overall_mshr_miss_rate 0.000571 # mshr miss rate for overall accesses
system.cpu.icache.ReadReq_avg_mshr_miss_latency 11739.649981 # average ReadReq mshr miss latency
system.cpu.icache.demand_avg_mshr_miss_latency 11739.649981 # average overall mshr miss latency
system.cpu.icache.overall_avg_mshr_miss_latency 11739.649981 # 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 159 # number of replacements
system.cpu.dcache.tagsinuse 1462.507461 # Cycle average of tags in use
system.cpu.dcache.total_refs 30399158 # Total number of references to valid blocks.
system.cpu.dcache.sampled_refs 2246 # Sample count of references to valid blocks.
system.cpu.dcache.avg_refs 13534.798753 # Average number of references to valid blocks.
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.dcache.warmup_cycle 0 # Cycle when the warmup percentage was hit.
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.occ_blocks::0 1462.507461 # Average occupied blocks per context
system.cpu.dcache.occ_percent::0 0.357057 # Average percentage of cache occupancy
system.cpu.dcache.ReadReq_hits 23906051 # number of ReadReq hits
system.cpu.dcache.WriteReq_hits 6493055 # number of WriteReq hits
system.cpu.dcache.LoadLockedReq_hits 52 # number of LoadLockedReq hits
system.cpu.dcache.demand_hits 30399106 # number of demand (read+write) hits
system.cpu.dcache.overall_hits 30399106 # number of overall hits
system.cpu.dcache.ReadReq_misses 938 # number of ReadReq misses
system.cpu.dcache.WriteReq_misses 8048 # number of WriteReq misses
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.LoadLockedReq_misses 1 # number of LoadLockedReq misses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.demand_misses 8986 # number of demand (read+write) misses
system.cpu.dcache.overall_misses 8986 # number of overall misses
system.cpu.dcache.ReadReq_miss_latency 28163500 # number of ReadReq miss cycles
system.cpu.dcache.WriteReq_miss_latency 289889000 # number of WriteReq miss cycles
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.LoadLockedReq_miss_latency 38000 # number of LoadLockedReq miss cycles
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.demand_miss_latency 318052500 # number of demand (read+write) miss cycles
system.cpu.dcache.overall_miss_latency 318052500 # number of overall miss cycles
system.cpu.dcache.ReadReq_accesses 23906989 # 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 6501103 # 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 53 # number of LoadLockedReq accesses(hits+misses)
system.cpu.dcache.demand_accesses 30408092 # number of demand (read+write) accesses
system.cpu.dcache.overall_accesses 30408092 # number of overall (read+write) accesses
system.cpu.dcache.ReadReq_miss_rate 0.000039 # miss rate for ReadReq accesses
StoreSet: Update stats for store-set clearing
2011-08-19 22:08:08 +02:00
system.cpu.dcache.WriteReq_miss_rate 0.001238 # miss rate for WriteReq accesses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.LoadLockedReq_miss_rate 0.018868 # miss rate for LoadLockedReq accesses
system.cpu.dcache.demand_miss_rate 0.000296 # miss rate for demand accesses
system.cpu.dcache.overall_miss_rate 0.000296 # miss rate for overall accesses
system.cpu.dcache.ReadReq_avg_miss_latency 30025.053305 # average ReadReq miss latency
system.cpu.dcache.WriteReq_avg_miss_latency 36020.004970 # average WriteReq miss latency
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.LoadLockedReq_avg_miss_latency 38000 # average LoadLockedReq miss latency
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.demand_avg_miss_latency 35394.224349 # average overall miss latency
system.cpu.dcache.overall_avg_miss_latency 35394.224349 # average overall miss latency
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.blocked_cycles::no_mshrs 2500 # 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_cycles::no_targets 0 # number of cycles access was blocked
system.cpu.dcache.blocked::no_mshrs 1 # number of cycles access was blocked
system.cpu.dcache.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.dcache.avg_blocked_cycles::no_mshrs 2500 # 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.avg_blocked_cycles::no_targets no_value # average number of cycles each access was blocked
system.cpu.dcache.fast_writes 0 # number of fast writes performed
system.cpu.dcache.cache_copies 0 # number of cache copies performed
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.writebacks 108 # number of writebacks
system.cpu.dcache.ReadReq_mshr_hits 424 # number of ReadReq MSHR hits
system.cpu.dcache.WriteReq_mshr_hits 6317 # number of WriteReq MSHR hits
system.cpu.dcache.demand_mshr_hits 6741 # number of demand (read+write) MSHR hits
system.cpu.dcache.overall_mshr_hits 6741 # number of overall MSHR hits
system.cpu.dcache.ReadReq_mshr_misses 514 # number of ReadReq MSHR misses
system.cpu.dcache.WriteReq_mshr_misses 1731 # number of WriteReq MSHR misses
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.LoadLockedReq_mshr_misses 1 # number of LoadLockedReq MSHR misses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.demand_mshr_misses 2245 # number of demand (read+write) MSHR misses
system.cpu.dcache.overall_mshr_misses 2245 # 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 16469500 # number of ReadReq MSHR miss cycles
system.cpu.dcache.WriteReq_mshr_miss_latency 61655000 # number of WriteReq MSHR miss cycles
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.LoadLockedReq_mshr_miss_latency 35000 # number of LoadLockedReq MSHR miss cycles
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.demand_mshr_miss_latency 78124500 # number of demand (read+write) MSHR miss cycles
system.cpu.dcache.overall_mshr_miss_latency 78124500 # 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.000021 # mshr miss rate for ReadReq accesses
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.WriteReq_mshr_miss_rate 0.000266 # mshr miss rate for WriteReq accesses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.LoadLockedReq_mshr_miss_rate 0.018868 # mshr miss rate for LoadLockedReq accesses
system.cpu.dcache.demand_mshr_miss_rate 0.000074 # mshr miss rate for demand accesses
system.cpu.dcache.overall_mshr_miss_rate 0.000074 # mshr miss rate for overall accesses
system.cpu.dcache.ReadReq_avg_mshr_miss_latency 32041.828794 # average ReadReq mshr miss latency
system.cpu.dcache.WriteReq_avg_mshr_miss_latency 35618.139804 # average WriteReq mshr miss latency
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.LoadLockedReq_avg_mshr_miss_latency 35000 # average LoadLockedReq mshr miss latency
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.demand_avg_mshr_miss_latency 34799.331849 # average overall mshr miss latency
system.cpu.dcache.overall_avg_mshr_miss_latency 34799.331849 # 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
system.cpu.l2cache.replacements 0 # number of replacements
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.tagsinuse 2400.275766 # Cycle average of tags in use
system.cpu.l2cache.total_refs 7666 # Total number of references to valid blocks.
system.cpu.l2cache.sampled_refs 3556 # Sample count of references to valid blocks.
system.cpu.l2cache.avg_refs 2.155793 # 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 2382.642182 # Average occupied blocks per context
system.cpu.l2cache.occ_blocks::1 17.633584 # Average occupied blocks per context
system.cpu.l2cache.occ_percent::0 0.072712 # Average percentage of cache occupancy
system.cpu.l2cache.occ_percent::1 0.000538 # Average percentage of cache occupancy
system.cpu.l2cache.ReadReq_hits 7655 # number of ReadReq hits
system.cpu.l2cache.Writeback_hits 108 # number of Writeback hits
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.l2cache.ReadExReq_hits 25 # number of ReadExReq hits
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.demand_hits 7680 # number of demand (read+write) hits
system.cpu.l2cache.overall_hits 7680 # number of overall hits
system.cpu.l2cache.ReadReq_misses 3488 # number of ReadReq misses
system.cpu.l2cache.ReadExReq_misses 1706 # number of ReadExReq misses
system.cpu.l2cache.demand_misses 5194 # number of demand (read+write) misses
system.cpu.l2cache.overall_misses 5194 # number of overall misses
system.cpu.l2cache.ReadReq_miss_latency 119792500 # number of ReadReq miss cycles
system.cpu.l2cache.ReadExReq_miss_latency 59244000 # number of ReadExReq miss cycles
system.cpu.l2cache.demand_miss_latency 179036500 # number of demand (read+write) miss cycles
system.cpu.l2cache.overall_miss_latency 179036500 # number of overall miss cycles
system.cpu.l2cache.ReadReq_accesses 11143 # number of ReadReq accesses(hits+misses)
system.cpu.l2cache.Writeback_accesses 108 # number of Writeback accesses(hits+misses)
system.cpu.l2cache.ReadExReq_accesses 1731 # number of ReadExReq accesses(hits+misses)
system.cpu.l2cache.demand_accesses 12874 # number of demand (read+write) accesses
system.cpu.l2cache.overall_accesses 12874 # number of overall (read+write) accesses
system.cpu.l2cache.ReadReq_miss_rate 0.313022 # miss rate for ReadReq accesses
system.cpu.l2cache.ReadExReq_miss_rate 0.985557 # miss rate for ReadExReq accesses
system.cpu.l2cache.demand_miss_rate 0.403449 # miss rate for demand accesses
system.cpu.l2cache.overall_miss_rate 0.403449 # miss rate for overall accesses
system.cpu.l2cache.ReadReq_avg_miss_latency 34344.180046 # average ReadReq miss latency
system.cpu.l2cache.ReadExReq_avg_miss_latency 34726.846424 # average ReadExReq miss latency
system.cpu.l2cache.demand_avg_miss_latency 34469.869080 # average overall miss latency
system.cpu.l2cache.overall_avg_miss_latency 34469.869080 # average overall miss latency
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.l2cache.blocked_cycles::no_mshrs 0 # number of cycles access was blocked
system.cpu.l2cache.blocked_cycles::no_targets 0 # number of cycles access was blocked
system.cpu.l2cache.blocked::no_mshrs 0 # number of cycles access was blocked
system.cpu.l2cache.blocked::no_targets 0 # number of cycles access was blocked
system.cpu.l2cache.avg_blocked_cycles::no_mshrs no_value # average number of cycles each access was blocked
system.cpu.l2cache.avg_blocked_cycles::no_targets no_value # average number of cycles each access was blocked
system.cpu.l2cache.fast_writes 0 # number of fast writes performed
system.cpu.l2cache.cache_copies 0 # number of cache copies performed
system.cpu.l2cache.writebacks 0 # number of writebacks
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 3488 # number of ReadReq MSHR misses
system.cpu.l2cache.ReadExReq_mshr_misses 1706 # number of ReadExReq MSHR misses
system.cpu.l2cache.demand_mshr_misses 5194 # number of demand (read+write) MSHR misses
system.cpu.l2cache.overall_mshr_misses 5194 # 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 108490000 # number of ReadReq MSHR miss cycles
system.cpu.l2cache.ReadExReq_mshr_miss_latency 53828000 # number of ReadExReq MSHR miss cycles
system.cpu.l2cache.demand_mshr_miss_latency 162318000 # number of demand (read+write) MSHR miss cycles
system.cpu.l2cache.overall_mshr_miss_latency 162318000 # 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.313022 # mshr miss rate for ReadReq accesses
system.cpu.l2cache.ReadExReq_mshr_miss_rate 0.985557 # mshr miss rate for ReadExReq accesses
system.cpu.l2cache.demand_mshr_miss_rate 0.403449 # mshr miss rate for demand accesses
system.cpu.l2cache.overall_mshr_miss_rate 0.403449 # mshr miss rate for overall accesses
system.cpu.l2cache.ReadReq_avg_mshr_miss_latency 31103.784404 # average ReadReq mshr miss latency
system.cpu.l2cache.ReadExReq_avg_mshr_miss_latency 31552.168816 # average ReadExReq mshr miss latency
system.cpu.l2cache.demand_avg_mshr_miss_latency 31251.058914 # average overall mshr miss latency
system.cpu.l2cache.overall_avg_mshr_miss_latency 31251.058914 # 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