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

516 lines
57 KiB
Text
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 new ordering fix.
2011-09-13 18:58:09 +02:00
sim_seconds 0.643030 # Number of seconds simulated
sim_ticks 643030478500 # 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 153773 # Simulator instruction rate (inst/s)
host_tick_rate 54239400 # Simulator tick rate (ticks/s)
host_mem_usage 218648 # Number of bytes of host memory used
host_seconds 11855.41 # 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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dtb.read_hits 520282071 # DTB read hits
system.cpu.dtb.read_misses 658976 # 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 520941047 # DTB read accesses
system.cpu.dtb.write_hits 283837075 # DTB write hits
system.cpu.dtb.write_misses 53680 # 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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dtb.write_accesses 283890755 # DTB write accesses
system.cpu.dtb.data_hits 804119146 # DTB hits
system.cpu.dtb.data_misses 712656 # 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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dtb.data_accesses 804831802 # DTB accesses
system.cpu.itb.fetch_hits 398310361 # ITB hits
system.cpu.itb.fetch_misses 225 # 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 398310586 # 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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.numCycles 1286060958 # 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 402586298 # Number of BP lookups
system.cpu.BPredUnit.condPredicted 267183275 # Number of conditional branches predicted
system.cpu.BPredUnit.condIncorrect 28898117 # Number of conditional branches incorrect
system.cpu.BPredUnit.BTBLookups 333702913 # Number of BTB lookups
system.cpu.BPredUnit.BTBHits 271687015 # 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 60998120 # Number of times the RAS was used to get a target.
system.cpu.BPredUnit.RASInCorrect 7269 # Number of incorrect RAS predictions.
system.cpu.fetch.icacheStallCycles 415096525 # Number of cycles fetch is stalled on an Icache miss
system.cpu.fetch.Insts 3352093116 # Number of instructions fetch has processed
system.cpu.fetch.Branches 402586298 # Number of branches that fetch encountered
system.cpu.fetch.predictedBranches 332685135 # Number of branches that fetch has predicted taken
system.cpu.fetch.Cycles 645195661 # Number of cycles fetch has run and was not squashing or blocked
system.cpu.fetch.SquashCycles 165271358 # Number of cycles fetch has spent squashing
system.cpu.fetch.BlockedCycles 89752324 # Number of cycles fetch has spent blocked
system.cpu.fetch.MiscStallCycles 146 # Number of cycles fetch has spent waiting on interrupts, or bad addresses, or out of MSHRs
system.cpu.fetch.PendingTrapStallCycles 4176 # Number of stall cycles due to pending traps
system.cpu.fetch.CacheLines 398310361 # Number of cache lines fetched
system.cpu.fetch.IcacheSquashes 11197226 # Number of outstanding Icache misses that were squashed
system.cpu.fetch.rateDist::samples 1285935042 # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::mean 2.606736 # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::stdev 3.132660 # 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 640739381 49.83% 49.83% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::1 57260959 4.45% 54.28% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::2 45174683 3.51% 57.79% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::3 73956325 5.75% 63.54% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::4 134643957 10.47% 74.01% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::5 43704830 3.40% 77.41% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::6 44948525 3.50% 80.91% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::7 8228368 0.64% 81.55% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::8 237278014 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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.fetch.rateDist::total 1285935042 # Number of instructions fetched each cycle (Total)
system.cpu.fetch.branchRate 0.313038 # Number of branch fetches per cycle
system.cpu.fetch.rate 2.606481 # Number of inst fetches per cycle
system.cpu.decode.IdleCycles 451176980 # Number of cycles decode is idle
system.cpu.decode.BlockedCycles 71498937 # Number of cycles decode is blocked
system.cpu.decode.RunCycles 618592802 # Number of cycles decode is running
system.cpu.decode.UnblockCycles 8792068 # Number of cycles decode is unblocking
system.cpu.decode.SquashCycles 135874255 # Number of cycles decode is squashing
system.cpu.decode.BranchResolved 30910962 # Number of times decode resolved a branch
system.cpu.decode.BranchMispred 12070 # Number of times decode detected a branch misprediction
system.cpu.decode.DecodedInsts 3252787569 # Number of instructions handled by decode
system.cpu.decode.SquashedInsts 45959 # Number of squashed instructions handled by decode
system.cpu.rename.SquashCycles 135874255 # Number of cycles rename is squashing
system.cpu.rename.IdleCycles 481268394 # Number of cycles rename is idle
system.cpu.rename.BlockCycles 29024257 # Number of cycles rename is blocking
system.cpu.rename.serializeStallCycles 25510 # count of cycles rename stalled for serializing inst
system.cpu.rename.RunCycles 595950971 # Number of cycles rename is running
system.cpu.rename.UnblockCycles 43791655 # Number of cycles rename is unblocking
system.cpu.rename.RenamedInsts 3151351284 # Number of instructions processed by rename
system.cpu.rename.ROBFullEvents 355 # Number of times rename has blocked due to ROB full
system.cpu.rename.IQFullEvents 750555 # Number of times rename has blocked due to IQ full
system.cpu.rename.LSQFullEvents 36590752 # Number of times rename has blocked due to LSQ full
system.cpu.rename.RenamedOperands 2105050619 # Number of destination operands rename has renamed
system.cpu.rename.RenameLookups 3698513195 # Number of register rename lookups that rename has made
system.cpu.rename.int_rename_lookups 3586317765 # Number of integer rename lookups
system.cpu.rename.fp_rename_lookups 112195430 # 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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.rename.UndoneMaps 720081549 # Number of HB maps that are undone due to squashing
StoreSet: Update stats for store-set clearing
2011-08-19 22:08:08 +02:00
system.cpu.rename.serializingInsts 4177 # count of serializing insts renamed
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.rename.tempSerializingInsts 82 # count of temporary serializing insts renamed
system.cpu.rename.skidInsts 124172087 # count of insts added to the skid buffer
system.cpu.memDep0.insertedLoads 732020123 # Number of loads inserted to the mem dependence unit.
system.cpu.memDep0.insertedStores 345520616 # Number of stores inserted to the mem dependence unit.
system.cpu.memDep0.conflictingLoads 66357929 # Number of conflicting loads.
system.cpu.memDep0.conflictingStores 8901879 # Number of conflicting stores.
system.cpu.iq.iqInstsAdded 2642218507 # Number of instructions added to the IQ (excludes non-spec)
system.cpu.iq.iqNonSpecInstsAdded 75 # Number of non-speculative instructions added to the IQ
system.cpu.iq.iqInstsIssued 2155449111 # Number of instructions issued
system.cpu.iq.iqSquashedInstsIssued 17941201 # Number of squashed instructions issued
system.cpu.iq.iqSquashedInstsExamined 818701684 # Number of squashed instructions iterated over during squash; mainly for profiling
system.cpu.iq.iqSquashedOperandsExamined 780988431 # Number of squashed operands that are examined and possibly removed from graph
system.cpu.iq.iqSquashedNonSpecRemoved 36 # Number of squashed non-spec instructions that were removed
system.cpu.iq.issued_per_cycle::samples 1285935042 # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::mean 1.676173 # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::stdev 1.767949 # 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 465245543 36.18% 36.18% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::1 229606292 17.86% 54.03% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::2 242969112 18.89% 72.93% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::3 129449912 10.07% 83.00% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::4 105111994 8.17% 91.17% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::5 71454382 5.56% 96.73% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::6 23774402 1.85% 98.58% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::7 15398679 1.20% 99.77% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::8 2924726 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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iq.issued_per_cycle::total 1285935042 # 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 19151 0.06% 0.06% # 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::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
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iq.fu_full::MemRead 21356146 65.69% 65.75% # attempts to use FU when none available
system.cpu.iq.fu_full::MemWrite 11134345 34.25% 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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iq.FU_type_0::IntAlu 1238361266 57.45% 57.45% # Type of FU issued
system.cpu.iq.FU_type_0::IntMult 16703 0.00% 57.45% # Type of FU issued
system.cpu.iq.FU_type_0::IntDiv 0 0.00% 57.45% # Type of FU issued
system.cpu.iq.FU_type_0::FloatAdd 27850917 1.29% 58.75% # Type of FU issued
system.cpu.iq.FU_type_0::FloatCmp 8254688 0.38% 59.13% # Type of FU issued
system.cpu.iq.FU_type_0::FloatCvt 7204646 0.33% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::FloatMult 4 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::FloatDiv 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::FloatSqrt 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdAdd 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdAddAcc 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdAlu 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdCmp 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdCvt 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdMisc 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdMult 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdMultAcc 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdShift 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdShiftAcc 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdSqrt 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatAdd 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatAlu 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatCmp 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatCvt 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatDiv 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatMisc 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatMult 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatMultAcc 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatSqrt 0 0.00% 59.46% # Type of FU issued
system.cpu.iq.FU_type_0::MemRead 584304865 27.11% 86.57% # Type of FU issued
system.cpu.iq.FU_type_0::MemWrite 289453270 13.43% 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 2155449111 # Type of FU issued
system.cpu.iq.rate 1.676009 # Inst issue rate
system.cpu.iq.fu_busy_cnt 32509642 # FU busy when requested
system.cpu.iq.fu_busy_rate 0.015083 # FU busy rate (busy events/executed inst)
system.cpu.iq.int_inst_queue_reads 5498808910 # Number of integer instruction queue reads
system.cpu.iq.int_inst_queue_writes 3382020905 # Number of integer instruction queue writes
system.cpu.iq.int_inst_queue_wakeup_accesses 1990959088 # Number of integer instruction queue wakeup accesses
system.cpu.iq.fp_inst_queue_reads 148475197 # Number of floating instruction queue reads
system.cpu.iq.fp_inst_queue_writes 78969876 # Number of floating instruction queue writes
system.cpu.iq.fp_inst_queue_wakeup_accesses 72622847 # Number of floating instruction queue wakeup accesses
system.cpu.iq.int_alu_accesses 2112315501 # Number of integer alu accesses
system.cpu.iq.fp_alu_accesses 75640500 # Number of floating point alu accesses
system.cpu.iew.lsq.thread0.forwLoads 67702370 # 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 220950097 # Number of loads squashed
system.cpu.iew.lsq.thread0.ignoredResponses 171000 # Number of memory responses ignored because the instruction is squashed
system.cpu.iew.lsq.thread0.memOrderViolation 71734 # Number of memory ordering violations
system.cpu.iew.lsq.thread0.squashedStores 134725720 # 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 4434 # Number of loads that were rescheduled
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.iew.lsq.thread0.cacheBlocked 21 # Number of times an access to memory failed due to the cache being blocked
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.iew.iewIdleCycles 0 # Number of cycles IEW is idle
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.iewSquashCycles 135874255 # Number of cycles IEW is squashing
system.cpu.iew.iewBlockCycles 3818188 # Number of cycles IEW is blocking
system.cpu.iew.iewUnblockCycles 203306 # Number of cycles IEW is unblocking
system.cpu.iew.iewDispatchedInsts 3005431260 # Number of instructions dispatched to IQ
system.cpu.iew.iewDispSquashedInsts 2750522 # Number of squashed instructions skipped by dispatch
system.cpu.iew.iewDispLoadInsts 732020123 # Number of dispatched load instructions
system.cpu.iew.iewDispStoreInsts 345520616 # Number of dispatched store instructions
system.cpu.iew.iewDispNonSpecInsts 75 # Number of dispatched non-speculative instructions
system.cpu.iew.iewIQFullEvents 131111 # 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 71734 # Number of memory order violations
system.cpu.iew.predictedTakenIncorrect 30723187 # Number of branches that were predicted taken incorrectly
system.cpu.iew.predictedNotTakenIncorrect 903682 # Number of branches that were predicted not taken incorrectly
system.cpu.iew.branchMispredicts 31626869 # Number of branch mispredicts detected at execute
system.cpu.iew.iewExecutedInsts 2066254472 # Number of executed instructions
system.cpu.iew.iewExecLoadInsts 520941220 # Number of load instructions executed
system.cpu.iew.iewExecSquashedInsts 89194639 # 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 363212678 # number of nop insts executed
system.cpu.iew.exec_refs 804832688 # number of memory reference insts executed
system.cpu.iew.exec_branches 279771397 # Number of branches executed
system.cpu.iew.exec_stores 283891468 # Number of stores executed
system.cpu.iew.exec_rate 1.606654 # Inst execution rate
system.cpu.iew.wb_sent 2065581707 # cumulative count of insts sent to commit
system.cpu.iew.wb_count 2063581935 # cumulative count of insts written-back
system.cpu.iew.wb_producers 1176945723 # num instructions producing a value
system.cpu.iew.wb_consumers 1742555439 # 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.604576 # insts written-back per cycle
system.cpu.iew.wb_fanout 0.675414 # 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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.commit.commitSquashedInsts 979738658 # 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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.commit.branchMispredicts 28886163 # The number of times a branch was mispredicted
system.cpu.commit.committed_per_cycle::samples 1150060787 # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::mean 1.746853 # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::stdev 2.513737 # 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 543040951 47.22% 47.22% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::1 216685952 18.84% 66.06% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::2 119778809 10.41% 76.47% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::3 61132291 5.32% 81.79% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::4 44136002 3.84% 85.63% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::5 24968433 2.17% 87.80% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::6 19265020 1.68% 89.47% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::7 16055764 1.40% 90.87% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::8 104997565 9.13% 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 1150060787 # 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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.commit.bw_lim_events 104997565 # 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 4028153074 # The number of ROB reads
system.cpu.rob.rob_writes 6113513811 # The number of ROB writes
system.cpu.timesIdled 3507 # Number of times that the entire CPU went into an idle state and unscheduled itself
system.cpu.idleCycles 125916 # 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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.cpi 0.705447 # CPI: Cycles Per Instruction
system.cpu.cpi_total 0.705447 # CPI: Total CPI of All Threads
system.cpu.ipc 1.417540 # IPC: Instructions Per Cycle
system.cpu.ipc_total 1.417540 # IPC: Total IPC of All Threads
system.cpu.int_regfile_reads 2630724063 # number of integer regfile reads
system.cpu.int_regfile_writes 1493026464 # number of integer regfile writes
system.cpu.fp_regfile_reads 77824314 # number of floating regfile reads
system.cpu.fp_regfile_writes 52830391 # number of floating regfile writes
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.misc_regfile_reads 1 # number of misc regfile reads
system.cpu.misc_regfile_writes 1 # number of misc regfile writes
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.icache.replacements 8239 # number of replacements
system.cpu.icache.tagsinuse 1650.873085 # Cycle average of tags in use
system.cpu.icache.total_refs 398299261 # Total number of references to valid blocks.
system.cpu.icache.sampled_refs 9946 # Sample count of references to valid blocks.
system.cpu.icache.avg_refs 40046.175447 # 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 1650.873085 # Average occupied blocks per context
system.cpu.icache.occ_percent::0 0.806090 # Average percentage of cache occupancy
system.cpu.icache.ReadReq_hits 398299261 # number of ReadReq hits
system.cpu.icache.demand_hits 398299261 # number of demand (read+write) hits
system.cpu.icache.overall_hits 398299261 # number of overall hits
system.cpu.icache.ReadReq_misses 11100 # number of ReadReq misses
system.cpu.icache.demand_misses 11100 # number of demand (read+write) misses
system.cpu.icache.overall_misses 11100 # number of overall misses
system.cpu.icache.ReadReq_miss_latency 182477500 # number of ReadReq miss cycles
system.cpu.icache.demand_miss_latency 182477500 # number of demand (read+write) miss cycles
system.cpu.icache.overall_miss_latency 182477500 # number of overall miss cycles
system.cpu.icache.ReadReq_accesses 398310361 # number of ReadReq accesses(hits+misses)
system.cpu.icache.demand_accesses 398310361 # number of demand (read+write) accesses
system.cpu.icache.overall_accesses 398310361 # number of overall (read+write) accesses
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
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
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.icache.ReadReq_avg_miss_latency 16439.414414 # average ReadReq miss latency
system.cpu.icache.demand_avg_miss_latency 16439.414414 # average overall miss latency
system.cpu.icache.overall_avg_miss_latency 16439.414414 # 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 1153 # number of ReadReq MSHR hits
system.cpu.icache.demand_mshr_hits 1153 # number of demand (read+write) MSHR hits
system.cpu.icache.overall_mshr_hits 1153 # number of overall MSHR hits
system.cpu.icache.ReadReq_mshr_misses 9947 # number of ReadReq MSHR misses
system.cpu.icache.demand_mshr_misses 9947 # number of demand (read+write) MSHR misses
system.cpu.icache.overall_mshr_misses 9947 # 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 119555000 # number of ReadReq MSHR miss cycles
system.cpu.icache.demand_mshr_miss_latency 119555000 # number of demand (read+write) MSHR miss cycles
system.cpu.icache.overall_mshr_miss_latency 119555000 # 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
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.icache.ReadReq_avg_mshr_miss_latency 12019.201769 # average ReadReq mshr miss latency
system.cpu.icache.demand_avg_mshr_miss_latency 12019.201769 # average overall mshr miss latency
system.cpu.icache.overall_avg_mshr_miss_latency 12019.201769 # 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 1527592 # number of replacements
system.cpu.dcache.tagsinuse 4095.113983 # Cycle average of tags in use
system.cpu.dcache.total_refs 660890207 # Total number of references to valid blocks.
system.cpu.dcache.sampled_refs 1531688 # Sample count of references to valid blocks.
system.cpu.dcache.avg_refs 431.478347 # Average number of references to valid blocks.
system.cpu.dcache.warmup_cycle 255376000 # Cycle when the warmup percentage was hit.
system.cpu.dcache.occ_blocks::0 4095.113983 # Average occupied blocks per context
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.occ_percent::0 0.999784 # Average percentage of cache occupancy
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.ReadReq_hits 450646939 # number of ReadReq hits
system.cpu.dcache.WriteReq_hits 210243259 # number of WriteReq hits
system.cpu.dcache.LoadLockedReq_hits 9 # number of LoadLockedReq hits
system.cpu.dcache.demand_hits 660890198 # number of demand (read+write) hits
system.cpu.dcache.overall_hits 660890198 # number of overall hits
system.cpu.dcache.ReadReq_misses 1928305 # number of ReadReq misses
system.cpu.dcache.WriteReq_misses 551637 # number of WriteReq misses
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.LoadLockedReq_misses 2 # number of LoadLockedReq misses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.demand_misses 2479942 # number of demand (read+write) misses
system.cpu.dcache.overall_misses 2479942 # number of overall misses
system.cpu.dcache.ReadReq_miss_latency 71444429000 # number of ReadReq miss cycles
system.cpu.dcache.WriteReq_miss_latency 20878144491 # number of WriteReq miss cycles
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.LoadLockedReq_miss_latency 59000 # 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 92322573491 # number of demand (read+write) miss cycles
system.cpu.dcache.overall_miss_latency 92322573491 # number of overall miss cycles
system.cpu.dcache.ReadReq_accesses 452575244 # 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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.LoadLockedReq_accesses 11 # number of LoadLockedReq accesses(hits+misses)
system.cpu.dcache.demand_accesses 663370140 # number of demand (read+write) accesses
system.cpu.dcache.overall_accesses 663370140 # number of overall (read+write) accesses
StoreSet: Update stats for store-set clearing
2011-08-19 22:08:08 +02:00
system.cpu.dcache.ReadReq_miss_rate 0.004261 # miss rate for ReadReq accesses
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.WriteReq_miss_rate 0.002617 # 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.181818 # miss rate for LoadLockedReq accesses
StoreSet: Update stats for store-set clearing
2011-08-19 22:08:08 +02:00
system.cpu.dcache.demand_miss_rate 0.003738 # miss rate for demand accesses
system.cpu.dcache.overall_miss_rate 0.003738 # miss rate for overall accesses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.ReadReq_avg_miss_latency 37050.377923 # average ReadReq miss latency
system.cpu.dcache.WriteReq_avg_miss_latency 37847.614448 # average WriteReq miss latency
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.LoadLockedReq_avg_miss_latency 29500 # 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 37227.714798 # average overall miss latency
system.cpu.dcache.overall_avg_miss_latency 37227.714798 # average overall miss latency
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.blocked_cycles::no_mshrs 79500 # number of cycles access was blocked
system.cpu.dcache.blocked_cycles::no_targets 20500 # number of cycles access was blocked
system.cpu.dcache.blocked::no_mshrs 14 # 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 LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.avg_blocked_cycles::no_mshrs 5678.571429 # average number of cycles each access was blocked
system.cpu.dcache.avg_blocked_cycles::no_targets 20500 # average number of cycles each access was blocked
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.dcache.fast_writes 0 # number of fast writes performed
system.cpu.dcache.cache_copies 0 # number of cache copies performed
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.writebacks 107326 # number of writebacks
system.cpu.dcache.ReadReq_mshr_hits 468223 # number of ReadReq MSHR hits
system.cpu.dcache.WriteReq_mshr_hits 480032 # number of WriteReq MSHR hits
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.LoadLockedReq_mshr_hits 1 # number of LoadLockedReq MSHR hits
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.demand_mshr_hits 948255 # number of demand (read+write) MSHR hits
system.cpu.dcache.overall_mshr_hits 948255 # number of overall MSHR hits
system.cpu.dcache.ReadReq_mshr_misses 1460082 # number of ReadReq MSHR misses
system.cpu.dcache.WriteReq_mshr_misses 71605 # 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 1531687 # number of demand (read+write) MSHR misses
system.cpu.dcache.overall_mshr_misses 1531687 # 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 49942277500 # number of ReadReq MSHR miss cycles
system.cpu.dcache.WriteReq_mshr_miss_latency 2493130000 # 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 52435407500 # number of demand (read+write) MSHR miss cycles
system.cpu.dcache.overall_mshr_miss_latency 52435407500 # 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
StoreSet: Update stats for store-set clearing
2011-08-19 22:08:08 +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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.LoadLockedReq_mshr_miss_rate 0.090909 # mshr miss rate for LoadLockedReq accesses
StoreSet: Update stats for store-set clearing
2011-08-19 22:08:08 +02:00
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
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.ReadReq_avg_mshr_miss_latency 34205.118274 # average ReadReq mshr miss latency
system.cpu.dcache.WriteReq_avg_mshr_miss_latency 34817.819985 # 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 34233.761532 # average overall mshr miss latency
system.cpu.dcache.overall_avg_mshr_miss_latency 34233.761532 # average overall mshr miss latency
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.dcache.overall_avg_mshr_uncacheable_latency no_value # average overall mshr uncacheable latency
system.cpu.dcache.mshr_cap_events 0 # number of times MSHR cap was activated
system.cpu.dcache.soft_prefetch_mshr_full 0 # number of mshr full events for SW prefetching instrutions
system.cpu.dcache.no_allocate_misses 0 # Number of misses that were no-allocate
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.replacements 1480630 # number of replacements
system.cpu.l2cache.tagsinuse 31935.913288 # Cycle average of tags in use
system.cpu.l2cache.total_refs 63583 # Total number of references to valid blocks.
system.cpu.l2cache.sampled_refs 1513317 # Sample count of references to valid blocks.
system.cpu.l2cache.avg_refs 0.042016 # 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 28876.475418 # Average occupied blocks per context
system.cpu.l2cache.occ_blocks::1 3059.437870 # Average occupied blocks per context
system.cpu.l2cache.occ_percent::0 0.881240 # Average percentage of cache occupancy
system.cpu.l2cache.occ_percent::1 0.093367 # Average percentage of cache occupancy
system.cpu.l2cache.ReadReq_hits 55959 # number of ReadReq hits
system.cpu.l2cache.Writeback_hits 107326 # number of Writeback hits
system.cpu.l2cache.ReadExReq_hits 4750 # number of ReadExReq hits
system.cpu.l2cache.demand_hits 60709 # number of demand (read+write) hits
system.cpu.l2cache.overall_hits 60709 # number of overall hits
system.cpu.l2cache.ReadReq_misses 1414071 # number of ReadReq misses
StoreSet: Update stats for store-set clearing
2011-08-19 22:08:08 +02:00
system.cpu.l2cache.ReadExReq_misses 66855 # number of ReadExReq misses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.demand_misses 1480926 # number of demand (read+write) misses
system.cpu.l2cache.overall_misses 1480926 # number of overall misses
system.cpu.l2cache.ReadReq_miss_latency 48513510000 # number of ReadReq miss cycles
system.cpu.l2cache.ReadExReq_miss_latency 2349021500 # number of ReadExReq miss cycles
system.cpu.l2cache.demand_miss_latency 50862531500 # number of demand (read+write) miss cycles
system.cpu.l2cache.overall_miss_latency 50862531500 # number of overall miss cycles
system.cpu.l2cache.ReadReq_accesses 1470030 # number of ReadReq accesses(hits+misses)
system.cpu.l2cache.Writeback_accesses 107326 # number of Writeback accesses(hits+misses)
system.cpu.l2cache.ReadExReq_accesses 71605 # number of ReadExReq accesses(hits+misses)
system.cpu.l2cache.demand_accesses 1541635 # number of demand (read+write) accesses
system.cpu.l2cache.overall_accesses 1541635 # number of overall (read+write) accesses
system.cpu.l2cache.ReadReq_miss_rate 0.961933 # miss rate for ReadReq accesses
system.cpu.l2cache.ReadExReq_miss_rate 0.933664 # miss rate for ReadExReq accesses
system.cpu.l2cache.demand_miss_rate 0.960620 # miss rate for demand accesses
system.cpu.l2cache.overall_miss_rate 0.960620 # miss rate for overall accesses
system.cpu.l2cache.ReadReq_avg_miss_latency 34307.690349 # average ReadReq miss latency
system.cpu.l2cache.ReadExReq_avg_miss_latency 35136.063122 # average ReadExReq miss latency
system.cpu.l2cache.demand_avg_miss_latency 34345.086453 # average overall miss latency
system.cpu.l2cache.overall_avg_miss_latency 34345.086453 # average overall miss latency
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.l2cache.blocked_cycles::no_mshrs 37500 # 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 LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.l2cache.blocked::no_mshrs 5 # 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 LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.l2cache.avg_blocked_cycles::no_mshrs 7500 # 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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.ReadReq_mshr_misses 1414071 # number of ReadReq MSHR misses
StoreSet: Update stats for store-set clearing
2011-08-19 22:08:08 +02:00
system.cpu.l2cache.ReadExReq_mshr_misses 66855 # number of ReadExReq MSHR misses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.demand_mshr_misses 1480926 # number of demand (read+write) MSHR misses
system.cpu.l2cache.overall_mshr_misses 1480926 # 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 new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.ReadReq_mshr_miss_latency 43837380500 # number of ReadReq MSHR miss cycles
system.cpu.l2cache.ReadExReq_mshr_miss_latency 2147695000 # number of ReadExReq MSHR miss cycles
system.cpu.l2cache.demand_mshr_miss_latency 45985075500 # number of demand (read+write) MSHR miss cycles
system.cpu.l2cache.overall_mshr_miss_latency 45985075500 # 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.961933 # mshr miss rate for ReadReq accesses
system.cpu.l2cache.ReadExReq_mshr_miss_rate 0.933664 # mshr miss rate for ReadExReq accesses
system.cpu.l2cache.demand_mshr_miss_rate 0.960620 # mshr miss rate for demand accesses
system.cpu.l2cache.overall_mshr_miss_rate 0.960620 # mshr miss rate for overall accesses
system.cpu.l2cache.ReadReq_avg_mshr_miss_latency 31000.834117 # average ReadReq mshr miss latency
system.cpu.l2cache.ReadExReq_avg_mshr_miss_latency 32124.672799 # average ReadExReq mshr miss latency
system.cpu.l2cache.demand_avg_mshr_miss_latency 31051.568748 # average overall mshr miss latency
system.cpu.l2cache.overall_avg_mshr_miss_latency 31051.568748 # 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