[m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
* build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/simple-atomic passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/o3-timing passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing-ruby passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-timing passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-timing-mp passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. *
Re: [m5-dev] Review Request: Regressions: Make X86_FS run automatically, and move it's regressions to quick.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/573/#review956 --- Ship it! - Steve On 2011-03-11 23:47:56, Gabe Black wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/573/ --- (Updated 2011-03-11 23:47:56) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- Regressions: Make X86_FS run automatically. Diffs - util/regress 5138d1e453f1 Diff: http://reviews.m5sim.org/r/573/diff Testing --- Thanks, Gabe ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: ARM: Identify branches as conditional or unconditional and direct or indirect.
On 2011-03-11 20:10:44, Ali Saidi wrote: src/cpu/o3/bpred_unit_impl.hh, line 354 http://reviews.m5sim.org/r/570/diff/1/?file=10843#file10843line354 Yea i was, that is why I changed it, but I can verify that it wasn't some other bug I'm not going to make any changes to the bpred_unit_impl.hh file... Apparently I fixed the issue I was having somewhere else. - Ali --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/570/#review955 --- On 2011-03-11 15:21:28, Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/570/ --- (Updated 2011-03-11 15:21:28) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- ARM: Identify branches as conditional or unconditional and direct or indirect. Diffs - src/arch/arm/insts/branch.hh 5138d1e453f1 src/arch/arm/isa/insts/branch.isa 5138d1e453f1 src/arch/arm/isa/templates/branch.isa 5138d1e453f1 src/arch/arm/predecoder.hh 5138d1e453f1 src/arch/arm/types.hh 5138d1e453f1 src/cpu/o3/bpred_unit_impl.hh 5138d1e453f1 Diff: http://reviews.m5sim.org/r/570/diff Testing --- Thanks, Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Functional Interface in Ruby
On Fri, 11 Mar 2011, Steve Reinhardt wrote: Thanks for the explanation... I was expecting to see a loop on L1DcacheMemory like before and I missed the one on system.ruby.network. In the short run, I think the easiest way to break the cycle is to have the network take the RubySystem object as a parameter instead of the other way around, then add a registerNetwork() callback on RubySystem to let the network give the system its pointer. There are more dependencies involved in here. RubySystem needs total memory size, which is calculated by looping through all the directory controllers. But the controllers themselves require RubySystem pointer. I still don't understand the opposition to cache controllers moving under RubySystem. They should logically be under RubySystem. Whenever we choose to remove RubySystem, everything will move under system. By having controllers under system and rest of Ruby components under RubySystem, we are creating two paths in the graph that are running parallel to each other, even though we have dependence between them. I would rather have a tree / directed acyclic structure. Thanks Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: SLICC: Remove the keyword wake_up_all_dependents
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/574/ --- Review request for Default. Summary --- SLICC: Remove the keyword wake_up_all_dependents In order to add stall and wait facility for protocols, a keyword wake_up_all_dependents was introduced. This patch removes the keyword, instead this functionality is now implemented as function call. Diffs - src/mem/protocol/MOESI_CMP_token-L1cache.sm 5138d1e453f1 src/mem/protocol/MOESI_hammer-cache.sm 5138d1e453f1 src/mem/slicc/ast/WakeUpAllDependentsStatementAST.py 5138d1e453f1 src/mem/slicc/parser.py 5138d1e453f1 src/mem/slicc/symbols/StateMachine.py 5138d1e453f1 Diff: http://reviews.m5sim.org/r/574/diff Testing --- Both MOESI Hammer and Token have been compiled and tested with random tester. Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Functional Interface in Ruby
On Sat, Mar 12, 2011 at 1:34 PM, Nilay Vaish ni...@cs.wisc.edu wrote: On Fri, 11 Mar 2011, Steve Reinhardt wrote: Thanks for the explanation... I was expecting to see a loop on L1DcacheMemory like before and I missed the one on system.ruby.network. In the short run, I think the easiest way to break the cycle is to have the network take the RubySystem object as a parameter instead of the other way around, then add a registerNetwork() callback on RubySystem to let the network give the system its pointer. There are more dependencies involved in here. RubySystem needs total memory size, which is calculated by looping through all the directory controllers. But the controllers themselves require RubySystem pointer. Can't we loop through the directory controllers in python to calculate the total size, then pass that size as a parameter to RubySystem? There's no reason for the C++ RubySystem object to need the directory controller pointers just to do that calculation. I still don't understand the opposition to cache controllers moving under RubySystem. They should logically be under RubySystem. Whenever we choose to remove RubySystem, everything will move under system. By having controllers under system and rest of Ruby components under RubySystem, we are creating two paths in the graph that are running parallel to each other, even though we have dependence between them. I would rather have a tree / directed acyclic structure. Yes, it's supposed to be an acyclic tree structure. What do you mean by cache controllers moving under RubySystem? As children or as parameters? They're not parameters of System now, and the fact that they're children of System isn't related to the parameter cycle we're trying to break. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Functional Interface in Ruby
On Sat, 12 Mar 2011, Steve Reinhardt wrote: On Sat, Mar 12, 2011 at 1:34 PM, Nilay Vaish ni...@cs.wisc.edu wrote: On Fri, 11 Mar 2011, Steve Reinhardt wrote: Thanks for the explanation... I was expecting to see a loop on L1DcacheMemory like before and I missed the one on system.ruby.network. In the short run, I think the easiest way to break the cycle is to have the network take the RubySystem object as a parameter instead of the other way around, then add a registerNetwork() callback on RubySystem to let the network give the system its pointer. There are more dependencies involved in here. RubySystem needs total memory size, which is calculated by looping through all the directory controllers. But the controllers themselves require RubySystem pointer. Can't we loop through the directory controllers in python to calculate the total size, then pass that size as a parameter to RubySystem? There's no reason for the C++ RubySystem object to need the directory controller pointers just to do that calculation. It is being done in Python script. We were thinking of passing RubySystem object to the Network. But RubySystem cannot be created before directory controllers are created. And the reason for these changes is to pass RubySystem object to the controllers. I still don't understand the opposition to cache controllers moving under RubySystem. They should logically be under RubySystem. Whenever we choose to remove RubySystem, everything will move under system. By having controllers under system and rest of Ruby components under RubySystem, we are creating two paths in the graph that are running parallel to each other, even though we have dependence between them. I would rather have a tree / directed acyclic structure. Yes, it's supposed to be an acyclic tree structure. What do you mean by cache controllers moving under RubySystem? As children or as parameters? They're not parameters of System now, and the fact that they're children of System isn't related to the parameter cycle we're trying to break. I would like to access cache controllers from RubySystem parameter object in C++. If we do allow such access, then we would not have any cycle in the graph. We only need to create controllers, then network and then RubySystem in Python. If controllers are visible to RubySystem as members of the RubySystem parameter object, then we can create the list of cache memories by probing each controller object. Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Functional Interface in Ruby
On Sat, Mar 12, 2011 at 5:45 PM, Nilay Vaish ni...@cs.wisc.edu wrote: On Sat, 12 Mar 2011, Steve Reinhardt wrote: Can't we loop through the directory controllers in python to calculate the total size, then pass that size as a parameter to RubySystem? There's no reason for the C++ RubySystem object to need the directory controller pointers just to do that calculation. It is being done in Python script. We were thinking of passing RubySystem object to the Network. But RubySystem cannot be created before directory controllers are created. And the reason for these changes is to pass RubySystem object to the controllers. I'm still confused... the python objects can be created in any order, and parameter values can be set at any time and in any order, up until the instantiate() call. The acyclic dependency issue only affects the creation of C++ objects in instantiate(). So I don't see how this is relevant. I would like to access cache controllers from RubySystem parameter object in C++. If we do allow such access, then we would not have any cycle in the graph. We only need to create controllers, then network and then RubySystem in Python. If controllers are visible to RubySystem as members of the RubySystem parameter object, then we can create the list of cache memories by probing each controller object. Yea, I can see that even though that's not the m5 idiom, and is a little less convenient since the python code has to explicitly build this list instead of having it happen implicitly, that it fits better with the way RubySystem is currently built up. Steve ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Regressions: Make X86_FS run automatically.
changeset e64347d17555 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=e64347d17555
description:
Regressions: Make X86_FS run automatically.
diffstat:
util/regress | 7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diffs (17 lines):
diff -r 5138d1e453f1 -r e64347d17555 util/regress
--- a/util/regress Fri Mar 11 11:27:36 2011 -0800
+++ b/util/regress Sat Mar 12 14:38:57 2011 -0800
@@ -45,7 +45,12 @@
'ALPHA_SE_MESI_CMP_directory,' \
'ALPHA_SE_MOESI_CMP_directory,' \
'ALPHA_SE_MOESI_CMP_token,' \
- 'ALPHA_FS,MIPS_SE,POWER_SE,SPARC_SE,SPARC_FS,X86_SE,ARM_SE,ARM_FS',
+ 'ALPHA_FS,' \
+ 'MIPS_SE,' \
+ 'POWER_SE,' \
+ 'SPARC_SE,SPARC_FS,' \
+ 'X86_SE,X86_FS,' \
+ 'ARM_SE,ARM_FS',
help=comma-separated build targets to test (default: '%default'))
add_option('--variants', dest='variants', default='fast',
help=comma-separated build variants to test (default: '%default'))
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Regressions: Move the X86_FS regressions to qu...
changeset 6c9b532da0a6 in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=6c9b532da0a6 description: Regressions: Move the X86_FS regressions to quick instead of long. diffstat: tests/long/10.linux-boot/ref/x86/linux/pc-simple-atomic/config.ini | 1174 -- tests/long/10.linux-boot/ref/x86/linux/pc-simple-atomic/simerr | 17 - tests/long/10.linux-boot/ref/x86/linux/pc-simple-atomic/simout | 17 - tests/long/10.linux-boot/ref/x86/linux/pc-simple-atomic/stats.txt | 540 tests/long/10.linux-boot/ref/x86/linux/pc-simple-atomic/system.pc.terminal | 133 - tests/long/10.linux-boot/ref/x86/linux/pc-simple-timing/config.ini | 1171 - tests/long/10.linux-boot/ref/x86/linux/pc-simple-timing/simerr | 17 - tests/long/10.linux-boot/ref/x86/linux/pc-simple-timing/simout | 17 - tests/long/10.linux-boot/ref/x86/linux/pc-simple-timing/stats.txt | 648 - tests/long/10.linux-boot/ref/x86/linux/pc-simple-timing/system.pc.terminal | 133 - tests/quick/10.linux-boot/ref/x86/linux/pc-simple-atomic/config.ini | 1174 ++ tests/quick/10.linux-boot/ref/x86/linux/pc-simple-atomic/simerr | 17 + tests/quick/10.linux-boot/ref/x86/linux/pc-simple-atomic/simout | 17 + tests/quick/10.linux-boot/ref/x86/linux/pc-simple-atomic/stats.txt | 542 tests/quick/10.linux-boot/ref/x86/linux/pc-simple-atomic/system.pc.terminal | 133 + tests/quick/10.linux-boot/ref/x86/linux/pc-simple-timing/config.ini | 1171 + tests/quick/10.linux-boot/ref/x86/linux/pc-simple-timing/simerr | 17 + tests/quick/10.linux-boot/ref/x86/linux/pc-simple-timing/simout | 17 + tests/quick/10.linux-boot/ref/x86/linux/pc-simple-timing/stats.txt | 650 + tests/quick/10.linux-boot/ref/x86/linux/pc-simple-timing/system.pc.terminal | 133 + 20 files changed, 3871 insertions(+), 3867 deletions(-) diffs (truncated from 7830 to 300 lines): diff -r e64347d17555 -r 6c9b532da0a6 tests/long/10.linux-boot/ref/x86/linux/pc-simple-atomic/config.ini --- a/tests/long/10.linux-boot/ref/x86/linux/pc-simple-atomic/config.ini Sat Mar 12 14:38:57 2011 -0800 +++ /dev/null Thu Jan 01 00:00:00 1970 + @@ -1,1174 +0,0 @@ -[root] -type=Root -children=system -time_sync_enable=false -time_sync_period=1000 -time_sync_spin_threshold=1 - -[system] -type=LinuxX86System -children=acpi_description_table_pointer bridge cpu e820_table intel_mp_pointer intel_mp_table intrctrl iobus iocache l2c membus pc physmem smbios_table toL2Bus -acpi_description_table_pointer=system.acpi_description_table_pointer -boot_cpu_frequency=500 -boot_osflags=earlyprintk=ttyS0 console=ttyS0 lpj=723 root=/dev/hda1 -e820_table=system.e820_table -init_param=0 -intel_mp_pointer=system.intel_mp_pointer -intel_mp_table=system.intel_mp_table -kernel=/dist/m5/system/binaries/x86_64-vmlinux-2.6.22.9 -load_addr_mask=18446744073709551615 -mem_mode=atomic -physmem=system.physmem -readfile=tests/halt.sh -smbios_table=system.smbios_table -symbolfile= -work_begin_ckpt_count=0 -work_begin_cpu_id_exit=-1 -work_begin_exit_count=0 -work_cpus_ckpt_count=0 -work_end_ckpt_count=0 -work_end_exit_count=0 -work_item_id=-1 - -[system.acpi_description_table_pointer] -type=X86ACPIRSDP -children=xsdt -oem_id= -revision=2 -rsdt=Null -xsdt=system.acpi_description_table_pointer.xsdt - -[system.acpi_description_table_pointer.xsdt] -type=X86ACPIXSDT -creator_id= -creator_revision=0 -entries= -oem_id= -oem_revision=0 -oem_table_id= - -[system.bridge] -type=Bridge -delay=5 -filter_ranges_a=0:1152921504606846975 -filter_ranges_b=0:134217727 -nack_delay=4000 -req_size_a=16 -req_size_b=16 -resp_size_a=16 -resp_size_b=16 -write_ack=false -side_a=system.iobus.port[0] -side_b=system.membus.port[1] - -[system.cpu] -type=AtomicSimpleCPU -children=dcache dtb dtb_walker_cache icache interrupts itb itb_walker_cache tracer -checker=Null -clock=500 -cpu_id=0 -defer_registration=false -do_checkpoint_insts=true -do_quiesce=true -do_statistics_insts=true -dtb=system.cpu.dtb -function_trace=false -function_trace_start=0 -interrupts=system.cpu.interrupts -itb=system.cpu.itb -max_insts_all_threads=0 -max_insts_any_thread=0 -max_loads_all_threads=0 -max_loads_any_thread=0 -numThreads=1 -phase=0 -profile=0 -progress_interval=0 -simulate_data_stalls=false -simulate_inst_stalls=false -system=system -tracer=system.cpu.tracer -width=1 -dcache_port=system.cpu.dcache.cpu_side -icache_port=system.cpu.icache.cpu_side - -[system.cpu.dcache] -type=BaseCache -addr_range=0:18446744073709551615 -assoc=4 -block_size=64 -forward_snoops=true -hash_delay=1 -latency=1000 -max_miss_count=0 -mshrs=4 -num_cpus=1 -prefetch_data_accesses_only=false -prefetch_degree=1 -prefetch_latency=1 -prefetch_on_access=false -prefetch_past_page=false
