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

251 lines
27 KiB
Text
Raw Normal View History

Add Alpha Linux version of "hello world" test. --HG-- extra : convert_revision : 22cd31c58f18fd92bd61ee4b4a218926f7290045
2006-08-21 04:48:30 +02:00
---------- Begin Simulation Statistics ----------
stats: update stats for preceding coherence changes Because the handling of the E state for multilevel caches has changed, stats are affected for any non-ruby config with caches, even uniprocessor simple CPU.
2010-09-09 20:40:19 +02:00
sim_seconds 0.000033 # Number of seconds simulated
sim_ticks 33007000 # 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
host_inst_rate 622879 # Simulator instruction rate (inst/s)
host_tick_rate 3204159632 # Simulator tick rate (ticks/s)
host_mem_usage 191816 # Number of bytes of host memory used
host_seconds 0.01 # Real time elapsed on the host
sim_insts 6404 # 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
This brings M5 closer to modernity - the kernel being advertised is newer so it won't die on binaries compiled with newer glibc's, and enables use of TLS-toolchain built binaries for ALPHA_SE by putting auxiliary vectors on the stack. There are some comments in the code to help. Finally, stats changes for ALPHA are from slight perturbations to the initial stack frame, all minimal diffs.
2008-12-05 18:09:29 +01:00
system.cpu.dtb.read_hits 1185 # DTB read hits
Stats: Update the stats. --HG-- extra : convert_revision : 888b6e3bcd432a9318d4b8741a8b274c6f37f1a8
2007-08-27 05:27:53 +02:00
system.cpu.dtb.read_misses 7 # 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
system.cpu.dtb.read_accesses 1192 # DTB read accesses
This brings M5 closer to modernity - the kernel being advertised is newer so it won't die on binaries compiled with newer glibc's, and enables use of TLS-toolchain built binaries for ALPHA_SE by putting auxiliary vectors on the stack. There are some comments in the code to help. Finally, stats changes for ALPHA are from slight perturbations to the initial stack frame, all minimal diffs.
2008-12-05 18:09:29 +01:00
system.cpu.dtb.write_hits 865 # DTB write hits
Stats: Update the stats. --HG-- extra : convert_revision : 888b6e3bcd432a9318d4b8741a8b274c6f37f1a8
2007-08-27 05:27:53 +02:00
system.cpu.dtb.write_misses 3 # 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
system.cpu.dtb.write_accesses 868 # DTB write accesses
system.cpu.dtb.data_hits 2050 # DTB hits
system.cpu.dtb.data_misses 10 # DTB misses
system.cpu.dtb.data_acv 0 # DTB access violations
system.cpu.dtb.data_accesses 2060 # DTB accesses
system.cpu.itb.fetch_hits 6415 # ITB hits
system.cpu.itb.fetch_misses 17 # ITB misses
system.cpu.itb.fetch_acv 0 # ITB acv
system.cpu.itb.fetch_accesses 6432 # ITB accesses
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
system.cpu.numCycles 66014 # number of cpu cycles simulated
system.cpu.numWorkItemsStarted 0 # number of work items this cpu started
system.cpu.numWorkItemsCompleted 0 # number of work items this cpu completed
system.cpu.num_insts 6404 # Number of instructions executed
system.cpu.num_int_alu_accesses 6331 # Number of integer alu accesses
system.cpu.num_fp_alu_accesses 10 # Number of float alu accesses
system.cpu.num_func_calls 251 # number of times a function call or return occured
system.cpu.num_conditional_control_insts 750 # number of instructions that are conditional controls
system.cpu.num_int_insts 6331 # number of integer instructions
system.cpu.num_fp_insts 10 # number of float instructions
system.cpu.num_int_register_reads 8304 # number of times the integer registers were read
system.cpu.num_int_register_writes 4581 # number of times the integer registers were written
system.cpu.num_fp_register_reads 8 # number of times the floating registers were read
system.cpu.num_fp_register_writes 2 # number of times the floating registers were written
system.cpu.num_mem_refs 2060 # number of memory refs
system.cpu.num_load_insts 1192 # Number of load instructions
system.cpu.num_store_insts 868 # Number of store instructions
system.cpu.num_idle_cycles 0 # Number of idle cycles
system.cpu.num_busy_cycles 66014 # Number of busy cycles
system.cpu.not_idle_fraction 1 # Percentage of non-idle cycles
system.cpu.idle_fraction 0 # Percentage of idle cycles
system.cpu.icache.replacements 0 # number of replacements
system.cpu.icache.tagsinuse 127.883393 # Cycle average of tags in use
system.cpu.icache.total_refs 6136 # Total number of references to valid blocks.
system.cpu.icache.sampled_refs 279 # Sample count of references to valid blocks.
system.cpu.icache.avg_refs 21.992832 # Average number of references to valid blocks.
system.cpu.icache.warmup_cycle 0 # Cycle when the warmup percentage was hit.
system.cpu.icache.occ_blocks::0 127.883393 # Average occupied blocks per context
system.cpu.icache.occ_percent::0 0.062443 # Average percentage of cache occupancy
This brings M5 closer to modernity - the kernel being advertised is newer so it won't die on binaries compiled with newer glibc's, and enables use of TLS-toolchain built binaries for ALPHA_SE by putting auxiliary vectors on the stack. There are some comments in the code to help. Finally, stats changes for ALPHA are from slight perturbations to the initial stack frame, all minimal diffs.
2008-12-05 18:09:29 +01:00
system.cpu.icache.ReadReq_hits 6136 # 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.icache.demand_hits 6136 # number of demand (read+write) hits
system.cpu.icache.overall_hits 6136 # number of overall hits
system.cpu.icache.ReadReq_misses 279 # number of ReadReq misses
system.cpu.icache.demand_misses 279 # number of demand (read+write) misses
system.cpu.icache.overall_misses 279 # number of overall misses
Make default PhysicalMemory latency slightly more realistic. Also update stats to reflect change.
2008-08-04 00:13:29 +02:00
system.cpu.icache.ReadReq_miss_latency 15582000 # number of ReadReq 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.demand_miss_latency 15582000 # number of demand (read+write) miss cycles
system.cpu.icache.overall_miss_latency 15582000 # number of overall miss cycles
system.cpu.icache.ReadReq_accesses 6415 # number of ReadReq accesses(hits+misses)
system.cpu.icache.demand_accesses 6415 # number of demand (read+write) accesses
system.cpu.icache.overall_accesses 6415 # number of overall (read+write) accesses
This brings M5 closer to modernity - the kernel being advertised is newer so it won't die on binaries compiled with newer glibc's, and enables use of TLS-toolchain built binaries for ALPHA_SE by putting auxiliary vectors on the stack. There are some comments in the code to help. Finally, stats changes for ALPHA are from slight perturbations to the initial stack frame, all minimal diffs.
2008-12-05 18:09:29 +01:00
system.cpu.icache.ReadReq_miss_rate 0.043492 # 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.icache.demand_miss_rate 0.043492 # miss rate for demand accesses
system.cpu.icache.overall_miss_rate 0.043492 # miss rate for overall accesses
system.cpu.icache.ReadReq_avg_miss_latency 55849.462366 # average ReadReq miss latency
system.cpu.icache.demand_avg_miss_latency 55849.462366 # average overall miss latency
system.cpu.icache.overall_avg_miss_latency 55849.462366 # average overall miss latency
stats: update reference outputs now that compatibility is gone Because of the initialization bug, it wasn't consistent anyway.
2009-04-22 19:25:17 +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
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::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
Add Alpha Linux version of "hello world" test. --HG-- extra : convert_revision : 22cd31c58f18fd92bd61ee4b4a218926f7290045
2006-08-21 04:48:30 +02:00
system.cpu.icache.cache_copies 0 # number of cache copies performed
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.writebacks 0 # number of writebacks
Add Alpha Linux version of "hello world" test. --HG-- extra : convert_revision : 22cd31c58f18fd92bd61ee4b4a218926f7290045
2006-08-21 04:48:30 +02:00
system.cpu.icache.demand_mshr_hits 0 # number of demand (read+write) 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.icache.overall_mshr_hits 0 # number of overall MSHR hits
system.cpu.icache.ReadReq_mshr_misses 279 # number of ReadReq MSHR misses
system.cpu.icache.demand_mshr_misses 279 # number of demand (read+write) MSHR misses
system.cpu.icache.overall_mshr_misses 279 # number of overall MSHR misses
system.cpu.icache.overall_mshr_uncacheable_misses 0 # number of overall MSHR uncacheable misses
system.cpu.icache.ReadReq_mshr_miss_latency 14745000 # number of ReadReq MSHR miss cycles
Make default PhysicalMemory latency slightly more realistic. Also update stats to reflect change.
2008-08-04 00:13:29 +02:00
system.cpu.icache.demand_mshr_miss_latency 14745000 # number of demand (read+write) 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_miss_latency 14745000 # number of overall MSHR miss cycles
system.cpu.icache.overall_mshr_uncacheable_latency 0 # number of overall MSHR uncacheable cycles
system.cpu.icache.ReadReq_mshr_miss_rate 0.043492 # mshr miss rate for ReadReq accesses
This brings M5 closer to modernity - the kernel being advertised is newer so it won't die on binaries compiled with newer glibc's, and enables use of TLS-toolchain built binaries for ALPHA_SE by putting auxiliary vectors on the stack. There are some comments in the code to help. Finally, stats changes for ALPHA are from slight perturbations to the initial stack frame, all minimal diffs.
2008-12-05 18:09:29 +01:00
system.cpu.icache.demand_mshr_miss_rate 0.043492 # mshr miss rate for demand accesses
alpha:o3:simple: update simout/err files A few prior changesets have changed the gem5 output in a way that wont cause errors but may be confusing for someone trying to debug the regressions. Ones that I caught were: - no more "warn: <hash address" - typo in the ALPHA Prefetch unimplemented warning Additionaly, the last updated stats changes rearrange the ordering of the stats output even though they are still correct stats (gem5 is smart enough to detect this). All the regressions pass w/the same stats even though it looks like they are being changed.
2011-06-21 00:57:14 +02:00
system.cpu.icache.overall_mshr_miss_rate 0.043492 # mshr miss rate for overall accesses
system.cpu.icache.ReadReq_avg_mshr_miss_latency 52849.462366 # average ReadReq mshr miss latency
system.cpu.icache.demand_avg_mshr_miss_latency 52849.462366 # average overall mshr miss latency
Make default PhysicalMemory latency slightly more realistic. Also update stats to reflect change.
2008-08-04 00:13:29 +02:00
system.cpu.icache.overall_avg_mshr_miss_latency 52849.462366 # average overall mshr miss latency
stats: update reference outputs now that compatibility is gone Because of the initialization bug, it wasn't consistent anyway.
2009-04-22 19:25:17 +02:00
system.cpu.icache.overall_avg_mshr_uncacheable_latency no_value # average overall mshr uncacheable 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.mshr_cap_events 0 # number of times MSHR cap was activated
Add Alpha Linux version of "hello world" test. --HG-- extra : convert_revision : 22cd31c58f18fd92bd61ee4b4a218926f7290045
2006-08-21 04:48:30 +02:00
system.cpu.icache.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.icache.no_allocate_misses 0 # Number of misses that were no-allocate
system.cpu.dcache.replacements 0 # number of replacements
system.cpu.dcache.tagsinuse 103.680615 # Cycle average of tags in use
system.cpu.dcache.total_refs 1882 # Total number of references to valid blocks.
system.cpu.dcache.sampled_refs 168 # Sample count of references to valid blocks.
system.cpu.dcache.avg_refs 11.202381 # Average number of references to valid blocks.
system.cpu.dcache.warmup_cycle 0 # Cycle when the warmup percentage was hit.
system.cpu.dcache.occ_blocks::0 103.680615 # Average occupied blocks per context
system.cpu.dcache.occ_percent::0 0.025313 # Average percentage of cache occupancy
system.cpu.dcache.ReadReq_hits 1090 # number of ReadReq hits
system.cpu.dcache.WriteReq_hits 792 # number of WriteReq hits
system.cpu.dcache.demand_hits 1882 # number of demand (read+write) hits
system.cpu.dcache.overall_hits 1882 # number of overall hits
system.cpu.dcache.ReadReq_misses 95 # number of ReadReq misses
system.cpu.dcache.WriteReq_misses 73 # number of WriteReq misses
system.cpu.dcache.demand_misses 168 # number of demand (read+write) misses
system.cpu.dcache.overall_misses 168 # number of overall misses
system.cpu.dcache.ReadReq_miss_latency 5320000 # number of ReadReq miss cycles
system.cpu.dcache.WriteReq_miss_latency 4088000 # number of WriteReq miss cycles
system.cpu.dcache.demand_miss_latency 9408000 # number of demand (read+write) miss cycles
system.cpu.dcache.overall_miss_latency 9408000 # number of overall miss cycles
system.cpu.dcache.ReadReq_accesses 1185 # number of ReadReq accesses(hits+misses)
system.cpu.dcache.WriteReq_accesses 865 # number of WriteReq accesses(hits+misses)
system.cpu.dcache.demand_accesses 2050 # number of demand (read+write) accesses
system.cpu.dcache.overall_accesses 2050 # number of overall (read+write) accesses
system.cpu.dcache.ReadReq_miss_rate 0.080169 # miss rate for ReadReq accesses
system.cpu.dcache.WriteReq_miss_rate 0.084393 # miss rate for WriteReq accesses
system.cpu.dcache.demand_miss_rate 0.081951 # miss rate for demand accesses
system.cpu.dcache.overall_miss_rate 0.081951 # miss rate for overall accesses
system.cpu.dcache.ReadReq_avg_miss_latency 56000 # average ReadReq miss latency
system.cpu.dcache.WriteReq_avg_miss_latency 56000 # average WriteReq miss latency
system.cpu.dcache.demand_avg_miss_latency 56000 # average overall miss latency
system.cpu.dcache.overall_avg_miss_latency 56000 # average overall miss latency
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
system.cpu.dcache.demand_mshr_hits 0 # number of demand (read+write) MSHR hits
system.cpu.dcache.overall_mshr_hits 0 # number of overall MSHR hits
system.cpu.dcache.ReadReq_mshr_misses 95 # number of ReadReq MSHR misses
system.cpu.dcache.WriteReq_mshr_misses 73 # number of WriteReq MSHR misses
system.cpu.dcache.demand_mshr_misses 168 # number of demand (read+write) MSHR misses
system.cpu.dcache.overall_mshr_misses 168 # number of overall MSHR misses
system.cpu.dcache.overall_mshr_uncacheable_misses 0 # number of overall MSHR uncacheable misses
system.cpu.dcache.ReadReq_mshr_miss_latency 5035000 # number of ReadReq MSHR miss cycles
system.cpu.dcache.WriteReq_mshr_miss_latency 3869000 # number of WriteReq MSHR miss cycles
system.cpu.dcache.demand_mshr_miss_latency 8904000 # number of demand (read+write) MSHR miss cycles
system.cpu.dcache.overall_mshr_miss_latency 8904000 # number of overall MSHR miss cycles
system.cpu.dcache.overall_mshr_uncacheable_latency 0 # number of overall MSHR uncacheable cycles
system.cpu.dcache.ReadReq_mshr_miss_rate 0.080169 # mshr miss rate for ReadReq accesses
system.cpu.dcache.WriteReq_mshr_miss_rate 0.084393 # mshr miss rate for WriteReq accesses
system.cpu.dcache.demand_mshr_miss_rate 0.081951 # mshr miss rate for demand accesses
system.cpu.dcache.overall_mshr_miss_rate 0.081951 # mshr miss rate for overall accesses
system.cpu.dcache.ReadReq_avg_mshr_miss_latency 53000 # average ReadReq mshr miss latency
system.cpu.dcache.WriteReq_avg_mshr_miss_latency 53000 # average WriteReq mshr miss latency
system.cpu.dcache.demand_avg_mshr_miss_latency 53000 # average overall mshr miss latency
system.cpu.dcache.overall_avg_mshr_miss_latency 53000 # average overall mshr miss latency
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
system.cpu.l2cache.tagsinuse 184.342479 # Cycle average of tags in use
system.cpu.l2cache.total_refs 1 # Total number of references to valid blocks.
system.cpu.l2cache.sampled_refs 373 # Sample count of references to valid blocks.
system.cpu.l2cache.avg_refs 0.002681 # Average number of references to valid blocks.
system.cpu.l2cache.warmup_cycle 0 # Cycle when the warmup percentage was hit.
system.cpu.l2cache.occ_blocks::0 184.342479 # Average occupied blocks per context
system.cpu.l2cache.occ_percent::0 0.005626 # Average percentage of cache occupancy
tests: new ref outputs for new cache model --HG-- extra : convert_revision : 244749072f97e425c2ca1cf296f2b95f37e99eb6
2007-08-04 00:04:30 +02:00
system.cpu.l2cache.ReadReq_hits 1 # 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.l2cache.demand_hits 1 # number of demand (read+write) hits
system.cpu.l2cache.overall_hits 1 # number of overall hits
system.cpu.l2cache.ReadReq_misses 373 # number of ReadReq misses
system.cpu.l2cache.ReadExReq_misses 73 # number of ReadExReq misses
system.cpu.l2cache.demand_misses 446 # number of demand (read+write) misses
system.cpu.l2cache.overall_misses 446 # number of overall misses
This brings M5 closer to modernity - the kernel being advertised is newer so it won't die on binaries compiled with newer glibc's, and enables use of TLS-toolchain built binaries for ALPHA_SE by putting auxiliary vectors on the stack. There are some comments in the code to help. Finally, stats changes for ALPHA are from slight perturbations to the initial stack frame, all minimal diffs.
2008-12-05 18:09:29 +01:00
system.cpu.l2cache.ReadReq_miss_latency 19396000 # number of ReadReq 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.ReadExReq_miss_latency 3796000 # number of ReadExReq miss cycles
system.cpu.l2cache.demand_miss_latency 23192000 # number of demand (read+write) miss cycles
system.cpu.l2cache.overall_miss_latency 23192000 # number of overall miss cycles
system.cpu.l2cache.ReadReq_accesses 374 # number of ReadReq accesses(hits+misses)
system.cpu.l2cache.ReadExReq_accesses 73 # number of ReadExReq accesses(hits+misses)
system.cpu.l2cache.demand_accesses 447 # number of demand (read+write) accesses
system.cpu.l2cache.overall_accesses 447 # number of overall (read+write) accesses
This brings M5 closer to modernity - the kernel being advertised is newer so it won't die on binaries compiled with newer glibc's, and enables use of TLS-toolchain built binaries for ALPHA_SE by putting auxiliary vectors on the stack. There are some comments in the code to help. Finally, stats changes for ALPHA are from slight perturbations to the initial stack frame, all minimal diffs.
2008-12-05 18:09:29 +01:00
system.cpu.l2cache.ReadReq_miss_rate 0.997326 # 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
system.cpu.l2cache.demand_miss_rate 0.997763 # miss rate for demand accesses
system.cpu.l2cache.overall_miss_rate 0.997763 # miss rate for overall accesses
system.cpu.l2cache.ReadReq_avg_miss_latency 52000 # average ReadReq miss latency
system.cpu.l2cache.ReadExReq_avg_miss_latency 52000 # average ReadExReq miss latency
system.cpu.l2cache.demand_avg_miss_latency 52000 # average overall miss latency
system.cpu.l2cache.overall_avg_miss_latency 52000 # average overall miss latency
stats: update reference outputs now that compatibility is gone Because of the initialization bug, it wasn't consistent anyway.
2009-04-22 19:25:17 +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
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_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
Add Alpha Linux version of "hello world" test. --HG-- extra : convert_revision : 22cd31c58f18fd92bd61ee4b4a218926f7290045
2006-08-21 04:48:30 +02:00
system.cpu.l2cache.cache_copies 0 # number of cache copies performed
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.writebacks 0 # number of writebacks
Add Alpha Linux version of "hello world" test. --HG-- extra : convert_revision : 22cd31c58f18fd92bd61ee4b4a218926f7290045
2006-08-21 04:48:30 +02:00
system.cpu.l2cache.demand_mshr_hits 0 # number of demand (read+write) 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.l2cache.overall_mshr_hits 0 # number of overall MSHR hits
system.cpu.l2cache.ReadReq_mshr_misses 373 # number of ReadReq MSHR misses
system.cpu.l2cache.ReadExReq_mshr_misses 73 # number of ReadExReq MSHR misses
system.cpu.l2cache.demand_mshr_misses 446 # number of demand (read+write) MSHR misses
system.cpu.l2cache.overall_mshr_misses 446 # number of overall MSHR misses
system.cpu.l2cache.overall_mshr_uncacheable_misses 0 # number of overall MSHR uncacheable misses
system.cpu.l2cache.ReadReq_mshr_miss_latency 14920000 # number of ReadReq MSHR miss cycles
system.cpu.l2cache.ReadExReq_mshr_miss_latency 2920000 # number of ReadExReq MSHR miss cycles
This brings M5 closer to modernity - the kernel being advertised is newer so it won't die on binaries compiled with newer glibc's, and enables use of TLS-toolchain built binaries for ALPHA_SE by putting auxiliary vectors on the stack. There are some comments in the code to help. Finally, stats changes for ALPHA are from slight perturbations to the initial stack frame, all minimal diffs.
2008-12-05 18:09:29 +01:00
system.cpu.l2cache.demand_mshr_miss_latency 17840000 # number of demand (read+write) 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_miss_latency 17840000 # number of overall MSHR miss cycles
system.cpu.l2cache.overall_mshr_uncacheable_latency 0 # number of overall MSHR uncacheable cycles
system.cpu.l2cache.ReadReq_mshr_miss_rate 0.997326 # mshr miss rate for ReadReq accesses
system.cpu.l2cache.ReadExReq_mshr_miss_rate 1 # mshr miss rate for ReadExReq accesses
This brings M5 closer to modernity - the kernel being advertised is newer so it won't die on binaries compiled with newer glibc's, and enables use of TLS-toolchain built binaries for ALPHA_SE by putting auxiliary vectors on the stack. There are some comments in the code to help. Finally, stats changes for ALPHA are from slight perturbations to the initial stack frame, all minimal diffs.
2008-12-05 18:09:29 +01:00
system.cpu.l2cache.demand_mshr_miss_rate 0.997763 # mshr miss rate for demand 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.overall_mshr_miss_rate 0.997763 # mshr miss rate for overall accesses
system.cpu.l2cache.ReadReq_avg_mshr_miss_latency 40000 # average ReadReq mshr miss latency
system.cpu.l2cache.ReadExReq_avg_mshr_miss_latency 40000 # average ReadExReq mshr miss latency
system.cpu.l2cache.demand_avg_mshr_miss_latency 40000 # average overall mshr miss latency
Make default PhysicalMemory latency slightly more realistic. Also update stats to reflect change.
2008-08-04 00:13:29 +02:00
system.cpu.l2cache.overall_avg_mshr_miss_latency 40000 # average overall mshr miss latency
stats: update reference outputs now that compatibility is gone Because of the initialization bug, it wasn't consistent anyway.
2009-04-22 19:25:17 +02:00
system.cpu.l2cache.overall_avg_mshr_uncacheable_latency no_value # average overall mshr uncacheable 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.mshr_cap_events 0 # number of times MSHR cap was activated
Add Alpha Linux version of "hello world" test. --HG-- extra : convert_revision : 22cd31c58f18fd92bd61ee4b4a218926f7290045
2006-08-21 04:48:30 +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 Alpha Linux version of "hello world" test. --HG-- extra : convert_revision : 22cd31c58f18fd92bd61ee4b4a218926f7290045
2006-08-21 04:48:30 +02:00
---------- End Simulation Statistics ----------
Reference in a new issue Copy permalink