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

509 lines
56 KiB
Text
Raw Normal View History

Add o3-timing configuration for ALPHA_SE "Hello world" tests. build_opts/ALPHA_SE: Add O3CPU to default CPU model list. tests/SConscript: Add o3-timing configuration. --HG-- extra : convert_revision : 378feacc07cefdaf1e2df9080c9b9d5d71e4d2a1
2006-09-01 23:59:36 +02:00
---------- Begin Simulation Statistics ----------
Make default PhysicalMemory latency slightly more realistic. Also update stats to reflect change.
2008-08-04 00:13:29 +02:00
sim_seconds 0.000012 # Number of seconds simulated
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
sim_ticks 12004500 # Number of ticks simulated
stats: Update stats for final tick and memory bandwidth patches
2012-01-25 18:19:50 +01:00
final_tick 12004500 # Number of ticks from beginning of simulation (restored from checkpoints and never reset)
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
sim_freq 1000000000000 # Frequency of simulated ticks
stats: Update stats for final tick and memory bandwidth patches
2012-01-25 18:19:50 +01:00
host_inst_rate 38695 # Simulator instruction rate (inst/s)
host_tick_rate 72731813 # Simulator tick rate (ticks/s)
host_mem_usage 208040 # Number of bytes of host memory used
host_seconds 0.17 # 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 6386 # Number of instructions simulated
stats: Update stats for final tick and memory bandwidth patches
2012-01-25 18:19:50 +01:00
system.physmem.bytes_read 31040 # Number of bytes read from this memory
system.physmem.bytes_inst_read 19904 # Number of instructions bytes read from this memory
system.physmem.bytes_written 0 # Number of bytes written to this memory
system.physmem.num_reads 485 # Number of read requests responded to by this memory
system.physmem.num_writes 0 # Number of write requests responded to by this memory
system.physmem.num_other 0 # Number of other requests responded to by this memory
system.physmem.bw_read 2585697030 # Total read bandwidth from this memory (bytes/s)
system.physmem.bw_inst_read 1658044900 # Instruction read bandwidth from this memory (bytes/s)
system.physmem.bw_total 2585697030 # Total bandwidth to/from this memory (bytes/s)
tests: update tests for TLB unification
2009-04-09 07:21:30 +02:00
system.cpu.dtb.fetch_hits 0 # ITB hits
system.cpu.dtb.fetch_misses 0 # ITB misses
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.dtb.fetch_acv 0 # ITB acv
system.cpu.dtb.fetch_accesses 0 # ITB accesses
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dtb.read_hits 1860 # DTB read hits
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dtb.read_misses 44 # 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 1904 # DTB read accesses
system.cpu.dtb.write_hits 1041 # DTB write hits
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dtb.write_misses 28 # 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 1069 # DTB write accesses
system.cpu.dtb.data_hits 2901 # DTB hits
system.cpu.dtb.data_misses 72 # 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 2973 # DTB accesses
system.cpu.itb.fetch_hits 2039 # ITB hits
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.itb.fetch_misses 29 # 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 2068 # ITB accesses
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.itb.read_hits 0 # DTB read hits
system.cpu.itb.read_misses 0 # DTB read misses
system.cpu.itb.read_acv 0 # DTB read access violations
system.cpu.itb.read_accesses 0 # DTB read accesses
system.cpu.itb.write_hits 0 # DTB write hits
system.cpu.itb.write_misses 0 # DTB write misses
system.cpu.itb.write_acv 0 # DTB write access violations
system.cpu.itb.write_accesses 0 # DTB write accesses
system.cpu.itb.data_hits 0 # DTB hits
system.cpu.itb.data_misses 0 # DTB misses
system.cpu.itb.data_acv 0 # DTB access violations
system.cpu.itb.data_accesses 0 # DTB accesses
system.cpu.workload.num_syscalls 17 # Number of system calls
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.numCycles 24010 # 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 2507 # Number of BP lookups
system.cpu.BPredUnit.condPredicted 1457 # Number of conditional branches predicted
system.cpu.BPredUnit.condIncorrect 459 # Number of conditional branches incorrect
system.cpu.BPredUnit.BTBLookups 1937 # Number of BTB lookups
system.cpu.BPredUnit.BTBHits 718 # 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 LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.BPredUnit.usedRAS 373 # Number of times the RAS was used to get a target.
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.BPredUnit.RASInCorrect 67 # Number of incorrect RAS predictions.
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.fetch.icacheStallCycles 7150 # Number of cycles fetch is stalled on an Icache miss
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.fetch.Insts 14456 # Number of instructions fetch has processed
system.cpu.fetch.Branches 2507 # Number of branches that fetch encountered
system.cpu.fetch.predictedBranches 1091 # Number of branches that fetch has predicted taken
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.fetch.Cycles 2619 # Number of cycles fetch has run and was not squashing or blocked
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.fetch.SquashCycles 1556 # Number of cycles fetch has spent squashing
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.fetch.BlockedCycles 1112 # Number of cycles fetch has spent blocked
system.cpu.fetch.MiscStallCycles 24 # Number of cycles fetch has spent waiting on interrupts, or bad addresses, or out of MSHRs
system.cpu.fetch.PendingTrapStallCycles 631 # Number of stall cycles due to pending traps
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.fetch.CacheLines 2039 # Number of cache lines fetched
system.cpu.fetch.IcacheSquashes 318 # Number of outstanding Icache misses that were squashed
system.cpu.fetch.rateDist::samples 12592 # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::mean 1.148030 # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::stdev 2.530696 # 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 9973 79.20% 79.20% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::1 274 2.18% 81.38% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::2 224 1.78% 83.16% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::3 222 1.76% 84.92% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::4 234 1.86% 86.78% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::5 178 1.41% 88.19% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::6 257 2.04% 90.23% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::7 140 1.11% 91.34% # Number of instructions fetched each cycle (Total)
system.cpu.fetch.rateDist::8 1090 8.66% 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 12592 # Number of instructions fetched each cycle (Total)
system.cpu.fetch.branchRate 0.104415 # Number of branch fetches per cycle
system.cpu.fetch.rate 0.602082 # Number of inst fetches per cycle
system.cpu.decode.IdleCycles 7970 # Number of cycles decode is idle
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.decode.BlockedCycles 1126 # Number of cycles decode is blocked
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.decode.RunCycles 2449 # Number of cycles decode is running
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.decode.UnblockCycles 69 # Number of cycles decode is unblocking
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.decode.SquashCycles 978 # Number of cycles decode is squashing
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.decode.BranchResolved 214 # Number of times decode resolved a branch
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.decode.BranchMispred 85 # Number of times decode detected a branch misprediction
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.decode.DecodedInsts 13378 # Number of instructions handled by decode
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.decode.SquashedInsts 215 # Number of squashed instructions handled by decode
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.rename.SquashCycles 978 # Number of cycles rename is squashing
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.rename.IdleCycles 8160 # Number of cycles rename is idle
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.rename.BlockCycles 432 # Number of cycles rename is blocking
system.cpu.rename.serializeStallCycles 358 # count of cycles rename stalled for serializing inst
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.rename.RunCycles 2318 # Number of cycles rename is running
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.rename.UnblockCycles 346 # Number of cycles rename is unblocking
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.rename.RenamedInsts 12829 # Number of instructions processed by rename
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.rename.IQFullEvents 11 # Number of times rename has blocked due to IQ full
system.cpu.rename.LSQFullEvents 291 # Number of times rename has blocked due to LSQ full
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.rename.RenamedOperands 9573 # Number of destination operands rename has renamed
system.cpu.rename.RenameLookups 16037 # Number of register rename lookups that rename has made
system.cpu.rename.int_rename_lookups 16020 # Number of integer 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.fp_rename_lookups 17 # Number of floating rename lookups
system.cpu.rename.CommittedMaps 4583 # 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 4990 # Number of HB maps that are undone due to squashing
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.rename.serializingInsts 28 # count of serializing insts renamed
system.cpu.rename.tempSerializingInsts 22 # count of temporary serializing insts renamed
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.rename.skidInsts 881 # count of insts added to the skid buffer
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.memDep0.insertedLoads 2391 # Number of loads inserted to the mem dependence unit.
system.cpu.memDep0.insertedStores 1271 # Number of stores inserted to the mem dependence unit.
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.memDep0.conflictingLoads 4 # Number of conflicting loads.
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.memDep0.conflictingStores 0 # Number of conflicting stores.
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iq.iqInstsAdded 11558 # Number of instructions added to the IQ (excludes non-spec)
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iq.iqNonSpecInstsAdded 27 # Number of non-speculative instructions added to the IQ
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iq.iqInstsIssued 9757 # Number of instructions issued
system.cpu.iq.iqSquashedInstsIssued 47 # Number of squashed instructions issued
system.cpu.iq.iqSquashedInstsExamined 4883 # Number of squashed instructions iterated over during squash; mainly for profiling
system.cpu.iq.iqSquashedOperandsExamined 2853 # Number of squashed operands that are examined and possibly removed from graph
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iq.iqSquashedNonSpecRemoved 10 # Number of squashed non-spec instructions that were removed
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iq.issued_per_cycle::samples 12592 # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::mean 0.774857 # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::stdev 1.395692 # 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 8510 67.58% 67.58% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::1 1462 11.61% 79.19% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::2 1072 8.51% 87.71% # Number of insts issued each cycle
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.iq.issued_per_cycle::3 685 5.44% 93.15% # 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::4 440 3.49% 96.64% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::5 254 2.02% 98.66% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::6 128 1.02% 99.67% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::7 30 0.24% 99.91% # Number of insts issued each cycle
system.cpu.iq.issued_per_cycle::8 11 0.09% 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 12592 # 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 13 12.26% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::IntMult 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::IntDiv 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatAdd 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatCmp 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatCvt 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatMult 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatDiv 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::FloatSqrt 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdAdd 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdAddAcc 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdAlu 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdCmp 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdCvt 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdMisc 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdMult 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdMultAcc 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdShift 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdShiftAcc 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdSqrt 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatAdd 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatAlu 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatCmp 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatCvt 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatDiv 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatMisc 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatMult 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatMultAcc 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::SimdFloatSqrt 0 0.00% 12.26% # attempts to use FU when none available
system.cpu.iq.fu_full::MemRead 54 50.94% 63.21% # attempts to use FU when none available
system.cpu.iq.fu_full::MemWrite 39 36.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 2 0.02% 0.02% # 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 6575 67.39% 67.41% # Type of FU issued
system.cpu.iq.FU_type_0::IntMult 1 0.01% 67.42% # Type of FU issued
system.cpu.iq.FU_type_0::IntDiv 0 0.00% 67.42% # Type of FU issued
system.cpu.iq.FU_type_0::FloatAdd 2 0.02% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::FloatCmp 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::FloatCvt 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::FloatMult 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::FloatDiv 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::FloatSqrt 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdAdd 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdAddAcc 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdAlu 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdCmp 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdCvt 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdMisc 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdMult 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdMultAcc 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdShift 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdShiftAcc 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdSqrt 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatAdd 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatAlu 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatCmp 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatCvt 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatDiv 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatMisc 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatMult 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatMultAcc 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::SimdFloatSqrt 0 0.00% 67.44% # Type of FU issued
system.cpu.iq.FU_type_0::MemRead 2074 21.26% 88.70% # Type of FU issued
system.cpu.iq.FU_type_0::MemWrite 1103 11.30% 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 9757 # Type of FU issued
system.cpu.iq.rate 0.406372 # Inst issue rate
system.cpu.iq.fu_busy_cnt 106 # FU busy when requested
system.cpu.iq.fu_busy_rate 0.010864 # FU busy rate (busy events/executed inst)
system.cpu.iq.int_inst_queue_reads 32238 # Number of integer instruction queue reads
system.cpu.iq.int_inst_queue_writes 16474 # Number of integer instruction queue writes
system.cpu.iq.int_inst_queue_wakeup_accesses 8982 # Number of integer instruction queue wakeup accesses
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.iq.fp_inst_queue_reads 21 # Number of floating instruction queue reads
system.cpu.iq.fp_inst_queue_writes 10 # Number of floating instruction queue writes
system.cpu.iq.fp_inst_queue_wakeup_accesses 10 # Number of floating instruction queue wakeup accesses
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.iq.int_alu_accesses 9850 # Number of integer alu accesses
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.iq.fp_alu_accesses 11 # Number of floating point alu accesses
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.iew.lsq.thread0.forwLoads 60 # 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 1206 # Number of loads squashed
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iew.lsq.thread0.ignoredResponses 0 # Number of memory responses ignored because the instruction is squashed
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.lsq.thread0.memOrderViolation 17 # Number of memory ordering violations
system.cpu.iew.lsq.thread0.squashedStores 406 # Number of stores squashed
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.iew.lsq.thread0.invAddrSwpfs 0 # Number of software prefetches ignored due to an invalid address
system.cpu.iew.lsq.thread0.blockedLoads 0 # Number of blocked loads due to partial load-store forwarding
system.cpu.iew.lsq.thread0.rescheduledLoads 1 # Number of loads that were rescheduled
system.cpu.iew.lsq.thread0.cacheBlocked 0 # Number of times an access to memory failed due to the cache being blocked
system.cpu.iew.iewIdleCycles 0 # Number of cycles IEW is idle
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.iewSquashCycles 978 # Number of cycles IEW is squashing
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iew.iewBlockCycles 150 # Number of cycles IEW is blocking
system.cpu.iew.iewUnblockCycles 8 # Number of cycles IEW is unblocking
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.iewDispatchedInsts 11665 # Number of instructions dispatched to IQ
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.iew.iewDispSquashedInsts 142 # Number of squashed instructions skipped by dispatch
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.iewDispLoadInsts 2391 # Number of dispatched load instructions
system.cpu.iew.iewDispStoreInsts 1271 # Number of dispatched store instructions
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iew.iewDispNonSpecInsts 27 # Number of dispatched non-speculative instructions
system.cpu.iew.iewIQFullEvents 5 # Number of times the IQ has become full, causing a stall
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.iewLSQFullEvents 0 # Number of times the LSQ has become full, causing a stall
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.memOrderViolationEvents 17 # Number of memory order violations
system.cpu.iew.predictedTakenIncorrect 120 # Number of branches that were predicted taken incorrectly
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iew.predictedNotTakenIncorrect 327 # Number of branches that were predicted not taken incorrectly
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.branchMispredicts 447 # Number of branch mispredicts detected at execute
system.cpu.iew.iewExecutedInsts 9313 # Number of executed instructions
system.cpu.iew.iewExecLoadInsts 1914 # Number of load instructions executed
system.cpu.iew.iewExecSquashedInsts 444 # Number of squashed instructions skipped in execute
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.iew.exec_swp 0 # number of swp insts executed
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.iew.exec_nop 80 # number of nop insts executed
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.exec_refs 2985 # number of memory reference insts executed
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.iew.exec_branches 1504 # Number of branches executed
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.exec_stores 1071 # Number of stores executed
system.cpu.iew.exec_rate 0.387880 # Inst execution rate
system.cpu.iew.wb_sent 9119 # cumulative count of insts sent to commit
system.cpu.iew.wb_count 8992 # cumulative count of insts written-back
system.cpu.iew.wb_producers 4719 # num instructions producing a value
system.cpu.iew.wb_consumers 6404 # num instructions consuming a value
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.iew.wb_penalized 0 # number of instrctions required to write to 'other' IQ
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.iew.wb_rate 0.374511 # insts written-back per cycle
system.cpu.iew.wb_fanout 0.736883 # 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 6403 # The number of committed instructions
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.commit.commitSquashedInsts 5259 # The number of squashed insts skipped by commit
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.commit.commitNonSpecStalls 17 # The number of times commit has been forced to stall to communicate backwards
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.commit.branchMispredicts 381 # The number of times a branch was mispredicted
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.commit.committed_per_cycle::samples 11614 # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::mean 0.551317 # 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::stdev 1.413084 # 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 LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.commit.committed_per_cycle::0 8938 76.96% 76.96% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::1 1410 12.14% 89.10% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::2 462 3.98% 93.08% # 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::3 240 2.07% 95.14% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::4 159 1.37% 96.51% # Number of insts commited each cycle
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.commit.committed_per_cycle::5 87 0.75% 97.26% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::6 110 0.95% 98.21% # 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::7 46 0.40% 98.61% # Number of insts commited each cycle
system.cpu.commit.committed_per_cycle::8 162 1.39% 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 LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.commit.committed_per_cycle::total 11614 # 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 6403 # Number of instructions committed
system.cpu.commit.swp_count 0 # Number of s/w prefetches committed
system.cpu.commit.refs 2050 # Number of memory references committed
system.cpu.commit.loads 1185 # Number of loads committed
system.cpu.commit.membars 0 # Number of memory barriers committed
system.cpu.commit.branches 1051 # Number of branches committed
system.cpu.commit.fp_insts 10 # Number of committed floating point instructions.
system.cpu.commit.int_insts 6321 # Number of committed integer instructions.
system.cpu.commit.function_calls 127 # 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 162 # 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 22763 # The number of ROB reads
system.cpu.rob.rob_writes 24313 # The number of ROB writes
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.timesIdled 230 # Number of times that the entire CPU went into an idle state and unscheduled itself
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.idleCycles 11418 # 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 6386 # Number of Instructions Simulated
system.cpu.committedInsts_total 6386 # Number of Instructions Simulated
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.cpi 3.759787 # CPI: Cycles Per Instruction
system.cpu.cpi_total 3.759787 # CPI: Total CPI of All Threads
system.cpu.ipc 0.265973 # IPC: Instructions Per Cycle
system.cpu.ipc_total 0.265973 # IPC: Total IPC of All Threads
system.cpu.int_regfile_reads 11830 # number of integer regfile reads
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.int_regfile_writes 6732 # number of integer regfile writes
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.fp_regfile_reads 8 # number of floating regfile reads
system.cpu.fp_regfile_writes 2 # number of floating regfile writes
system.cpu.misc_regfile_reads 1 # number of misc regfile reads
system.cpu.misc_regfile_writes 1 # number of misc regfile writes
system.cpu.icache.replacements 0 # number of replacements
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.icache.tagsinuse 160.112304 # Cycle average of tags in use
system.cpu.icache.total_refs 1606 # Total number of references to valid blocks.
system.cpu.icache.sampled_refs 312 # Sample count of references to valid blocks.
system.cpu.icache.avg_refs 5.147436 # 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 160.112304 # Average occupied blocks per context
system.cpu.icache.occ_percent::0 0.078180 # Average percentage of cache occupancy
system.cpu.icache.ReadReq_hits 1606 # number of ReadReq hits
system.cpu.icache.demand_hits 1606 # number of demand (read+write) hits
system.cpu.icache.overall_hits 1606 # number of overall hits
system.cpu.icache.ReadReq_misses 433 # number of ReadReq misses
system.cpu.icache.demand_misses 433 # number of demand (read+write) misses
system.cpu.icache.overall_misses 433 # number of overall misses
system.cpu.icache.ReadReq_miss_latency 15431000 # number of ReadReq miss cycles
system.cpu.icache.demand_miss_latency 15431000 # number of demand (read+write) miss cycles
system.cpu.icache.overall_miss_latency 15431000 # number of overall miss cycles
system.cpu.icache.ReadReq_accesses 2039 # number of ReadReq accesses(hits+misses)
system.cpu.icache.demand_accesses 2039 # number of demand (read+write) accesses
system.cpu.icache.overall_accesses 2039 # number of overall (read+write) accesses
system.cpu.icache.ReadReq_miss_rate 0.212359 # miss rate for ReadReq accesses
system.cpu.icache.demand_miss_rate 0.212359 # miss rate for demand accesses
system.cpu.icache.overall_miss_rate 0.212359 # miss rate for overall accesses
system.cpu.icache.ReadReq_avg_miss_latency 35637.413395 # average ReadReq miss latency
system.cpu.icache.demand_avg_miss_latency 35637.413395 # average overall miss latency
system.cpu.icache.overall_avg_miss_latency 35637.413395 # average overall miss latency
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.icache.blocked_cycles::no_mshrs 0 # number of cycles access was blocked
system.cpu.icache.blocked_cycles::no_targets 0 # number of cycles access was blocked
system.cpu.icache.blocked::no_mshrs 0 # number of cycles access was blocked
system.cpu.icache.blocked::no_targets 0 # number of cycles access was blocked
system.cpu.icache.avg_blocked_cycles::no_mshrs no_value # average number of cycles each access was blocked
system.cpu.icache.avg_blocked_cycles::no_targets no_value # average number of cycles each access was blocked
system.cpu.icache.fast_writes 0 # number of fast writes performed
system.cpu.icache.cache_copies 0 # number of cache copies performed
system.cpu.icache.writebacks 0 # number of writebacks
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.icache.ReadReq_mshr_hits 121 # number of ReadReq MSHR hits
system.cpu.icache.demand_mshr_hits 121 # number of demand (read+write) MSHR hits
system.cpu.icache.overall_mshr_hits 121 # number of overall MSHR hits
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.icache.ReadReq_mshr_misses 312 # number of ReadReq MSHR misses
system.cpu.icache.demand_mshr_misses 312 # number of demand (read+write) MSHR misses
system.cpu.icache.overall_mshr_misses 312 # 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 11021000 # number of ReadReq MSHR miss cycles
system.cpu.icache.demand_mshr_miss_latency 11021000 # number of demand (read+write) MSHR miss cycles
system.cpu.icache.overall_mshr_miss_latency 11021000 # 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.153016 # mshr miss rate for ReadReq accesses
system.cpu.icache.demand_mshr_miss_rate 0.153016 # mshr miss rate for demand accesses
system.cpu.icache.overall_mshr_miss_rate 0.153016 # mshr miss rate for overall accesses
system.cpu.icache.ReadReq_avg_mshr_miss_latency 35323.717949 # average ReadReq mshr miss latency
system.cpu.icache.demand_avg_mshr_miss_latency 35323.717949 # average overall mshr miss latency
system.cpu.icache.overall_avg_mshr_miss_latency 35323.717949 # 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
system.cpu.dcache.replacements 0 # number of replacements
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.tagsinuse 109.290272 # Cycle average of tags in use
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.total_refs 2154 # Total 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.sampled_refs 174 # Sample count of references to valid blocks.
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.avg_refs 12.379310 # 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 109.290272 # Average occupied blocks per context
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.occ_percent::0 0.026682 # Average percentage of cache occupancy
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.ReadReq_hits 1645 # number of ReadReq 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.dcache.WriteReq_hits 509 # number of WriteReq hits
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.demand_hits 2154 # number of demand (read+write) hits
system.cpu.dcache.overall_hits 2154 # number of overall hits
system.cpu.dcache.ReadReq_misses 154 # number of ReadReq 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_misses 356 # number of WriteReq misses
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.demand_misses 510 # number of demand (read+write) misses
system.cpu.dcache.overall_misses 510 # number of overall misses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.ReadReq_miss_latency 5497500 # number of ReadReq miss cycles
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.WriteReq_miss_latency 12467500 # number of WriteReq miss cycles
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.demand_miss_latency 17965000 # number of demand (read+write) miss cycles
system.cpu.dcache.overall_miss_latency 17965000 # number of overall miss cycles
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.ReadReq_accesses 1799 # 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 865 # number of WriteReq accesses(hits+misses)
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.demand_accesses 2664 # number of demand (read+write) accesses
system.cpu.dcache.overall_accesses 2664 # number of overall (read+write) accesses
system.cpu.dcache.ReadReq_miss_rate 0.085603 # 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_miss_rate 0.411561 # miss rate for WriteReq accesses
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.demand_miss_rate 0.191441 # miss rate for demand accesses
system.cpu.dcache.overall_miss_rate 0.191441 # 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 35698.051948 # average ReadReq miss latency
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.WriteReq_avg_miss_latency 35021.067416 # average WriteReq miss latency
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.dcache.demand_avg_miss_latency 35225.490196 # average overall miss latency
system.cpu.dcache.overall_avg_miss_latency 35225.490196 # average overall miss latency
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.dcache.blocked_cycles::no_mshrs 0 # number of cycles access was blocked
system.cpu.dcache.blocked_cycles::no_targets 0 # number of cycles access was blocked
system.cpu.dcache.blocked::no_mshrs 0 # number of cycles access was blocked
system.cpu.dcache.blocked::no_targets 0 # number of cycles access was blocked
system.cpu.dcache.avg_blocked_cycles::no_mshrs no_value # average number of cycles each access was blocked
system.cpu.dcache.avg_blocked_cycles::no_targets no_value # average number of cycles each access was blocked
system.cpu.dcache.fast_writes 0 # number of fast writes performed
system.cpu.dcache.cache_copies 0 # number of cache copies performed
system.cpu.dcache.writebacks 0 # number of writebacks
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.ReadReq_mshr_hits 53 # number of ReadReq MSHR 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.dcache.WriteReq_mshr_hits 283 # number of WriteReq MSHR hits
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.demand_mshr_hits 336 # number of demand (read+write) MSHR hits
system.cpu.dcache.overall_mshr_hits 336 # number of overall MSHR 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.dcache.ReadReq_mshr_misses 101 # number of ReadReq MSHR misses
system.cpu.dcache.WriteReq_mshr_misses 73 # number of WriteReq MSHR misses
system.cpu.dcache.demand_mshr_misses 174 # number of demand (read+write) MSHR misses
system.cpu.dcache.overall_mshr_misses 174 # number of overall MSHR misses
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 3654500 # number of ReadReq MSHR miss cycles
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.WriteReq_mshr_miss_latency 2611500 # number of WriteReq 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 6266000 # number of demand (read+write) MSHR miss cycles
system.cpu.dcache.overall_mshr_miss_latency 6266000 # 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 LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.ReadReq_mshr_miss_rate 0.056142 # 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.084393 # mshr miss rate for WriteReq accesses
O3: Update stats for LSQ changes.
2011-08-19 22:08:06 +02:00
system.cpu.dcache.demand_mshr_miss_rate 0.065315 # mshr miss rate for demand accesses
system.cpu.dcache.overall_mshr_miss_rate 0.065315 # 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 36183.168317 # average ReadReq mshr miss latency
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.dcache.WriteReq_avg_mshr_miss_latency 35773.972603 # average WriteReq 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 36011.494253 # average overall mshr miss latency
system.cpu.dcache.overall_avg_mshr_miss_latency 36011.494253 # 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 221.643066 # Cycle average of tags in use
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.l2cache.total_refs 1 # Total number of references to valid blocks.
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.sampled_refs 412 # Sample count of references to valid blocks.
system.cpu.l2cache.avg_refs 0.002427 # 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 221.643066 # Average occupied blocks per context
system.cpu.l2cache.occ_percent::0 0.006764 # Average percentage of cache occupancy
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.ReadReq_hits 1 # number of ReadReq hits
system.cpu.l2cache.demand_hits 1 # number of demand (read+write) hits
system.cpu.l2cache.overall_hits 1 # number of overall hits
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.ReadReq_misses 412 # number of ReadReq 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.l2cache.ReadExReq_misses 73 # number of ReadExReq misses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.demand_misses 485 # number of demand (read+write) misses
system.cpu.l2cache.overall_misses 485 # number of overall misses
system.cpu.l2cache.ReadReq_miss_latency 14163000 # number of ReadReq miss cycles
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.l2cache.ReadExReq_miss_latency 2513500 # number of ReadExReq miss cycles
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.demand_miss_latency 16676500 # number of demand (read+write) miss cycles
system.cpu.l2cache.overall_miss_latency 16676500 # number of overall miss cycles
system.cpu.l2cache.ReadReq_accesses 413 # 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.l2cache.ReadExReq_accesses 73 # number of ReadExReq accesses(hits+misses)
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.demand_accesses 486 # number of demand (read+write) accesses
system.cpu.l2cache.overall_accesses 486 # number of overall (read+write) accesses
system.cpu.l2cache.ReadReq_miss_rate 0.997579 # 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.l2cache.ReadExReq_miss_rate 1 # miss rate for ReadExReq accesses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.demand_miss_rate 0.997942 # miss rate for demand accesses
system.cpu.l2cache.overall_miss_rate 0.997942 # miss rate for overall accesses
system.cpu.l2cache.ReadReq_avg_miss_latency 34376.213592 # average ReadReq miss latency
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.l2cache.ReadExReq_avg_miss_latency 34431.506849 # average ReadExReq miss latency
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.demand_avg_miss_latency 34384.536082 # average overall miss latency
system.cpu.l2cache.overall_avg_miss_latency 34384.536082 # 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
Add o3-timing configuration for ALPHA_SE "Hello world" tests. build_opts/ALPHA_SE: Add O3CPU to default CPU model list. tests/SConscript: Add o3-timing configuration. --HG-- extra : convert_revision : 378feacc07cefdaf1e2df9080c9b9d5d71e4d2a1
2006-09-01 23:59:36 +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 412 # number of ReadReq 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.l2cache.ReadExReq_mshr_misses 73 # 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 485 # number of demand (read+write) MSHR misses
system.cpu.l2cache.overall_mshr_misses 485 # number of overall MSHR misses
Add o3-timing configuration for ALPHA_SE "Hello world" tests. build_opts/ALPHA_SE: Add O3CPU to default CPU model list. tests/SConscript: Add o3-timing configuration. --HG-- extra : convert_revision : 378feacc07cefdaf1e2df9080c9b9d5d71e4d2a1
2006-09-01 23:59:36 +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 12850000 # number of ReadReq MSHR miss cycles
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.l2cache.ReadExReq_mshr_miss_latency 2286000 # number of ReadExReq MSHR miss cycles
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.demand_mshr_miss_latency 15136000 # number of demand (read+write) MSHR miss cycles
system.cpu.l2cache.overall_mshr_miss_latency 15136000 # 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.997579 # 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.l2cache.ReadExReq_mshr_miss_rate 1 # mshr miss rate for ReadExReq accesses
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.demand_mshr_miss_rate 0.997942 # mshr miss rate for demand accesses
system.cpu.l2cache.overall_mshr_miss_rate 0.997942 # mshr miss rate for overall accesses
system.cpu.l2cache.ReadReq_avg_mshr_miss_latency 31189.320388 # average ReadReq mshr miss latency
O3: Update stats for fetch and bp changes.
2011-07-10 19:56:09 +02:00
system.cpu.l2cache.ReadExReq_avg_mshr_miss_latency 31315.068493 # average ReadExReq mshr miss latency
O3: Update stats for new ordering fix.
2011-09-13 18:58:09 +02:00
system.cpu.l2cache.demand_avg_mshr_miss_latency 31208.247423 # average overall mshr miss latency
system.cpu.l2cache.overall_avg_mshr_miss_latency 31208.247423 # 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
Add o3-timing configuration for ALPHA_SE "Hello world" tests. build_opts/ALPHA_SE: Add O3CPU to default CPU model list. tests/SConscript: Add o3-timing configuration. --HG-- extra : convert_revision : 378feacc07cefdaf1e2df9080c9b9d5d71e4d2a1
2006-09-01 23:59:36 +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
Add o3-timing configuration for ALPHA_SE "Hello world" tests. build_opts/ALPHA_SE: Add O3CPU to default CPU model list. tests/SConscript: Add o3-timing configuration. --HG-- extra : convert_revision : 378feacc07cefdaf1e2df9080c9b9d5d71e4d2a1
2006-09-01 23:59:36 +02:00
---------- End Simulation Statistics ----------
Reference in a new issue Copy permalink