[m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
* build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/opt/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/opt/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_FS/tests/opt/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/inorder-timing passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/o3-timing passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/simple-timing-ruby passed. * build/MIPS_SE/tests/opt/quick/00.hello/mips/linux/simple-timing passed. * build/POWER_SE/tests/opt/quick/00.hello/power/linux/o3-timing passed. * build/POWER_SE/tests/opt/quick/00.hello/power/linux/simple-atomic passed. * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-atomic passed. * build/ALPHA_SE/tests/opt/quick/50.memtest/alpha/linux/memtest passed. * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/opt/quick/00.hello/sparc/linux/simple-timing-ruby passed. * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/o3-timing passed. * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/opt/quick/02.insttest/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/opt/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp passed. *
[m5-dev] debug-help broken
$ ./build/ARM_FS/m5.opt --debug-help Base Flags: Traceback (most recent call last): File , line 1, in File /work/m5/src/python/m5/main.py, line 238, in main debug.help() File /work/m5/src/python/m5/debug.py, line 35, in help for flag in flags.basic: AttributeError: 'AllFlags' object has no attribute 'basic' What is supposed to happen here? Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] debug-help broken
Also, --trace-flags still exists in the code and just silently does nothing. Ali On Tue, 03 May 2011 12:11:30 -0500, Ali Saidi sa...@umich.edu wrote: $ ./build/ARM_FS/m5.opt --debug-help Base Flags: Traceback (most recent call last): File , line 1, in File /work/m5/src/python/m5/main.py, line 238, in main debug.help() File /work/m5/src/python/m5/debug.py, line 35, in help for flag in flags.basic: AttributeError: 'AllFlags' object has no attribute 'basic' What is supposed to happen here? Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] debug-help broken
would it be so bad if we had trace-flags and debug-flags mean the same thing on the command line? I should've spoke up earlier because I actually like trace-flags over debug-flags. On Tue, May 3, 2011 at 1:15 PM, Ali Saidi sa...@umich.edu wrote: Also, --trace-flags still exists in the code and just silently does nothing. Ali On Tue, 03 May 2011 12:11:30 -0500, Ali Saidi sa...@umich.edu wrote: $ ./build/ARM_FS/m5.opt --debug-help Base Flags: Traceback (most recent call last): File , line 1, in File /work/m5/src/python/m5/main.py, line 238, in main debug.help() File /work/m5/src/python/m5/debug.py, line 35, in help for flag in flags.basic: AttributeError: 'AllFlags' object has no attribute 'basic' What is supposed to happen here? Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev -- - Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: CPU: Fix a case where timing simple cpu faults can nest.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/670/#review1190 --- Could you please walk through when two faults will happen at the same time and why that's a problem? src/cpu/simple/timing.cc http://reviews.m5sim.org/r/670/#comment1646 The reschedule function (with always set) will do the de/rescheduling for you all in one shot. - Gabe On 2011-05-02 15:41:43, Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/670/ --- (Updated 2011-05-02 15:41:43) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- CPU: Fix a case where timing simple cpu faults can nest. If we fault, change the state to faulting so that we don't fault again in the same cycle. Diffs - src/cpu/simple/base.hh 3f49ed206f46 src/cpu/simple/timing.cc 3f49ed206f46 Diff: http://reviews.m5sim.org/r/670/diff Testing --- Thanks, Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: ruby-stats: support for dump_stats instruction
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/675/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- ruby-stats: support for dump_stats instruction *** NOTE: The core changes for this diff are in Profiler.cc/hh, stat_control.hh/cc, and pseudo_inst.cc This is a first pass toward getting dump-stats functionality to work cleanly for Ruby. As is, the patch works, but there needs to be discussion over: - Changing Ruby typedef Time to RTime because it conflicts with the Time class defined in base/time.hh (The majority of files are renames)... Is there a better name than RTime? - Where is the right place for this RubyStatEvent code? I hesitated to do any real cosmetic changes because of what impending stat changes might do. I have two thoughts: (1) If Ruby Stats will be registered like old M5 stats, then this code would nicely fold into the old statEvent code in sim_control.cc. Fold into maybe too strong of a phrase even, as most of it should just naturally work. (2) If Ruby Stats are not registered, then maybe placing this code into the RubySystem class. I realized late that the Profiler and Network have two different stats that they track so the RubySystem would be the right place along with calling the namespace RubyStats. Diffs - SConstruct 3f49ed206f46 src/cpu/testers/rubytest/RubyTester.hh 3f49ed206f46 src/cpu/testers/rubytest/RubyTester.cc 3f49ed206f46 src/mem/ruby/buffers/MessageBuffer.hh 3f49ed206f46 src/mem/ruby/buffers/MessageBuffer.cc 3f49ed206f46 src/mem/ruby/buffers/MessageBufferNode.hh 3f49ed206f46 src/mem/ruby/common/Consumer.hh 3f49ed206f46 src/mem/ruby/common/Global.hh 3f49ed206f46 src/mem/ruby/common/TypeDefines.hh 3f49ed206f46 src/mem/ruby/eventqueue/RubyEventQueue.hh 3f49ed206f46 src/mem/ruby/eventqueue/RubyEventQueue.cc 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/InputUnit_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/OutVcState_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/VirtualChannel_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/flit_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/FlexibleConsumer.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/InVcState.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/InVcState.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/NetworkLink.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/NetworkLink.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/OutVcState.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/OutVcState.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/Router.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/Router.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/flit.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/flit.cc 3f49ed206f46 src/mem/ruby/network/simple/Throttle.hh 3f49ed206f46 src/mem/ruby/profiler/Profiler.hh 3f49ed206f46 src/mem/ruby/profiler/Profiler.cc 3f49ed206f46 src/mem/ruby/profiler/StoreTrace.hh 3f49ed206f46 src/mem/ruby/profiler/StoreTrace.cc 3f49ed206f46 src/mem/ruby/recorder/CacheRecorder.hh 3f49ed206f46 src/mem/ruby/recorder/CacheRecorder.cc 3f49ed206f46 src/mem/ruby/recorder/TraceRecord.hh 3f49ed206f46 src/mem/ruby/recorder/TraceRecord.cc 3f49ed206f46 src/mem/ruby/recorder/Tracer.hh 3f49ed206f46 src/mem/ruby/recorder/Tracer.cc 3f49ed206f46 src/mem/ruby/slicc_interface/AbstractCacheEntry.hh 3f49ed206f46 src/mem/ruby/slicc_interface/Message.hh 3f49ed206f46 src/mem/ruby/slicc_interface/RubySlicc_Util.hh 3f49ed206f46 src/mem/ruby/system/AbstractReplacementPolicy.hh 3f49ed206f46 src/mem/ruby/system/LRUPolicy.hh 3f49ed206f46 src/mem/ruby/system/MemoryControl.cc 3f49ed206f46 src/mem/ruby/system/MemoryNode.hh 3f49ed206f46 src/mem/ruby/system/PseudoLRUPolicy.hh 3f49ed206f46 src/mem/ruby/system/Sequencer.hh 3f49ed206f46 src/mem/ruby/system/Sequencer.cc 3f49ed206f46 src/mem/ruby/system/System.hh 3f49ed206f46 src/mem/ruby/system/System.cc 3f49ed206f46 src/mem/ruby/system/TimerTable.hh
Re: [m5-dev] Review Request: CPU: Fix a case where timing simple cpu faults can nest.
On 2011-05-03 11:13:49, Gabe Black wrote: Could you please walk through when two faults will happen at the same time and why that's a problem? mem op - tlb miss - delayed translation - table walk - fault - fetch - tlb miss - table walk The table walker should never be called twice in one cycle. After the first fault we really want to unwind the call stack, let a cycle go by, and then start fetching handling the next instruction. These cases generate traces that are super hard to debug, unrealistic, and make debugging challenging so we should avoid them. On 2011-05-03 11:13:49, Gabe Black wrote: src/cpu/simple/timing.cc, line 784 http://reviews.m5sim.org/r/670/diff/1/?file=12217#file12217line784 The reschedule function (with always set) will do the de/rescheduling for you all in one shot. will fix. - Ali --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/670/#review1190 --- On 2011-05-02 15:41:43, Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/670/ --- (Updated 2011-05-02 15:41:43) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- CPU: Fix a case where timing simple cpu faults can nest. If we fault, change the state to faulting so that we don't fault again in the same cycle. Diffs - src/cpu/simple/base.hh 3f49ed206f46 src/cpu/simple/timing.cc 3f49ed206f46 Diff: http://reviews.m5sim.org/r/670/diff Testing --- Thanks, Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: CPU: Fix a case where timing simple cpu faults can nest.
On 2011-05-03 11:13:49, Gabe Black wrote: Could you please walk through when two faults will happen at the same time and why that's a problem? Ali Saidi wrote: mem op - tlb miss - delayed translation - table walk - fault - fetch - tlb miss - table walk The table walker should never be called twice in one cycle. After the first fault we really want to unwind the call stack, let a cycle go by, and then start fetching handling the next instruction. These cases generate traces that are super hard to debug, unrealistic, and make debugging challenging so we should avoid them. Ah, ok. I think this is similar to that problem where the call stack wraps back around on itself too many times and tracedata gets deleted out from under an earlier frame by a later frame. It's good to break that cycle here, I think. I didn't see anything (other than my comment below) that was objectionable, so if you've tested it go ahead. - Gabe --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/670/#review1190 --- On 2011-05-02 15:41:43, Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/670/ --- (Updated 2011-05-02 15:41:43) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- CPU: Fix a case where timing simple cpu faults can nest. If we fault, change the state to faulting so that we don't fault again in the same cycle. Diffs - src/cpu/simple/base.hh 3f49ed206f46 src/cpu/simple/timing.cc 3f49ed206f46 Diff: http://reviews.m5sim.org/r/670/diff Testing --- Thanks, Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: network: added Torus and Pt2Pt topologies
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/667/#review1193 --- Ship it! Overall, this looks good to me. One thing you may consider is giving the wrap-around links a higher latency. src/mem/ruby/network/topologies/Torus.py http://reviews.m5sim.org/r/667/#comment1648 Should we give the wrap-around links a higher latency? src/mem/ruby/network/topologies/Torus.py http://reviews.m5sim.org/r/667/#comment1649 Same here, higher latency? - Brad On 2011-04-29 15:58:51, Tushar Krishna wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/667/ --- (Updated 2011-04-29 15:58:51) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan Binkert, and Brad Beckmann. Summary --- network: added Torus and Pt2Pt topologies Diffs - src/mem/ruby/network/topologies/Pt2Pt.py PRE-CREATION src/mem/ruby/network/topologies/SConscript 7939dd0c4ff2 src/mem/ruby/network/topologies/Torus.py PRE-CREATION Diff: http://reviews.m5sim.org/r/667/diff Testing --- Thanks, Tushar ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: NetworkTest: added sim_cycles parameter to the network tester.
On 2011-04-29 15:27:14, Tushar Krishna wrote: src/cpu/testers/networktest/networktest.cc, line 213 http://reviews.m5sim.org/r/660/diff/1/?file=12042#file12042line213 Hey Brad, One concern that I have with my current implementation here is that if --fixed-pkts is enabled, then the tester is not scheduled after injecting maxPackets. Once all packets are delivered (= no more events from the network side as well), there is no agent to call exitSimLoop to end the simulation, so it ends at m5's max tick (9223372036854775807) cycles. This does not slow down the simulation (since there are no events after all delivery), and is ok. But it does screw up the power stats etc which use Ruby_cycles, and sort of looks ugly since m5 prints out that the simulation ended after 9223372036854775807 cycles. One option is to end the simulation as soon as the tester injects maxPackets, but that wont result in all packets getting delivered, defeating the purpose of fixed-pkts which I added for network debugging. The other option is to keep scheduling the tester till simCycles, but simply stopping the generation of packets after maxPackets (this was what I was doing earlier). But this requires the simCycles input to be greater than the time by which all packets are expected to be injected (which depends upon maxPackets and injection rate). [Unlike the ruby random tester, the tester here does not track anything to determine when everything is delivered]. Any suggestions? Thanks, Tushar I don't think there is an easy way to support the fixed-pkts option based on the current NetworkTest implementation. Ending the simulation as soon as the tester injects maxPackets seems likek the only reasonable thing to do. Unless we can remove the fixed-pkts option all together. The other options seem like brittle hacks. If you want to spend a bit more time on it, I suspect we could provide the directory a pointer to the NetworkTest object and have the directory call say a NetworkTest.finish() function. - Brad --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/660/#review1172 --- On 2011-04-25 16:18:04, Tushar Krishna wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/660/ --- (Updated 2011-04-25 16:18:04) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan Binkert, and Brad Beckmann. Summary --- NetworkTest: added sim_cycles parameter to the network tester. The network tester terminates after injecting for sim_cycles (default=1000), instead of having to explicitly pass --maxtick from the command line as before. If fixed_pkts is enabled, the tester stops scheduling itself after injecting maxpackets number of packets. The tester also works with zero command line arguments now. Diffs - configs/example/ruby_network_test.py de679a068dd8 src/cpu/testers/networktest/NetworkTest.py de679a068dd8 src/cpu/testers/networktest/networktest.hh de679a068dd8 src/cpu/testers/networktest/networktest.cc de679a068dd8 Diff: http://reviews.m5sim.org/r/660/diff Testing --- Thanks, Tushar ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: ruby-stats: support for dump_stats instruction
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/675/#review1195 --- Can we change the name of Time in base/time.hh instead of Time in Ruby? Right now this patch touches 50+ Ruby files and a bunch of lines within those files just to change Time to RTime. It seems that far fewer changes would be required to change the name of base/time.hh's version of Time. src/mem/ruby/profiler/Profiler.cc http://reviews.m5sim.org/r/675/#comment1651 Why do you have to create a separate namespace here? src/mem/ruby/system/System.hh http://reviews.m5sim.org/r/675/#comment1652 Why does this need to be static? I think we want to avoid making it more difficult to run Ruby in a multiple system scenario. src/sim/pseudo_inst.cc http://reviews.m5sim.org/r/675/#comment1653 Why is the RUBY compile flag necessary? - Brad On 2011-05-03 11:20:58, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/675/ --- (Updated 2011-05-03 11:20:58) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- ruby-stats: support for dump_stats instruction *** NOTE: The core changes for this diff are in Profiler.cc/hh, stat_control.hh/cc, and pseudo_inst.cc This is a first pass toward getting dump-stats functionality to work cleanly for Ruby. As is, the patch works, but there needs to be discussion over: - Changing Ruby typedef Time to RTime because it conflicts with the Time class defined in base/time.hh (The majority of files are renames)... Is there a better name than RTime? - Where is the right place for this RubyStatEvent code? I hesitated to do any real cosmetic changes because of what impending stat changes might do. I have two thoughts: (1) If Ruby Stats will be registered like old M5 stats, then this code would nicely fold into the old statEvent code in sim_control.cc. Fold into maybe too strong of a phrase even, as most of it should just naturally work. (2) If Ruby Stats are not registered, then maybe placing this code into the RubySystem class. I realized late that the Profiler and Network have two different stats that they track so the RubySystem would be the right place along with calling the namespace RubyStats. Diffs - SConstruct 3f49ed206f46 src/cpu/testers/rubytest/RubyTester.hh 3f49ed206f46 src/cpu/testers/rubytest/RubyTester.cc 3f49ed206f46 src/mem/ruby/buffers/MessageBuffer.hh 3f49ed206f46 src/mem/ruby/buffers/MessageBuffer.cc 3f49ed206f46 src/mem/ruby/buffers/MessageBufferNode.hh 3f49ed206f46 src/mem/ruby/common/Consumer.hh 3f49ed206f46 src/mem/ruby/common/Global.hh 3f49ed206f46 src/mem/ruby/common/TypeDefines.hh 3f49ed206f46 src/mem/ruby/eventqueue/RubyEventQueue.hh 3f49ed206f46 src/mem/ruby/eventqueue/RubyEventQueue.cc 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/InputUnit_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/OutVcState_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/VirtualChannel_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/flit_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/FlexibleConsumer.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/InVcState.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/InVcState.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/NetworkLink.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/NetworkLink.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/OutVcState.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/OutVcState.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/Router.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/Router.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/flit.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/flit.cc 3f49ed206f46 src/mem/ruby/network/simple/Throttle.hh 3f49ed206f46 src/mem/ruby/profiler/Profiler.hh 3f49ed206f46
Re: [m5-dev] Review Request: ruby-stats: support for dump_stats instruction
On 2011-05-03 17:45:41, Brad Beckmann wrote: Can we change the name of Time in base/time.hh instead of Time in Ruby? Right now this patch touches 50+ Ruby files and a bunch of lines within those files just to change Time to RTime. It seems that far fewer changes would be required to change the name of base/time.hh's version of Time. While I wouldn't be opposed to changing the time in base/time.hh if we needed both, but don't we need to move ruby away from its own version of Time anyway? Shouldn't we be using Tick? Also, we've generally never shied away from changes that can be done with a one line sed/perl script. - Nathan --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/675/#review1195 --- On 2011-05-03 11:20:58, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/675/ --- (Updated 2011-05-03 11:20:58) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- ruby-stats: support for dump_stats instruction *** NOTE: The core changes for this diff are in Profiler.cc/hh, stat_control.hh/cc, and pseudo_inst.cc This is a first pass toward getting dump-stats functionality to work cleanly for Ruby. As is, the patch works, but there needs to be discussion over: - Changing Ruby typedef Time to RTime because it conflicts with the Time class defined in base/time.hh (The majority of files are renames)... Is there a better name than RTime? - Where is the right place for this RubyStatEvent code? I hesitated to do any real cosmetic changes because of what impending stat changes might do. I have two thoughts: (1) If Ruby Stats will be registered like old M5 stats, then this code would nicely fold into the old statEvent code in sim_control.cc. Fold into maybe too strong of a phrase even, as most of it should just naturally work. (2) If Ruby Stats are not registered, then maybe placing this code into the RubySystem class. I realized late that the Profiler and Network have two different stats that they track so the RubySystem would be the right place along with calling the namespace RubyStats. Diffs - SConstruct 3f49ed206f46 src/cpu/testers/rubytest/RubyTester.hh 3f49ed206f46 src/cpu/testers/rubytest/RubyTester.cc 3f49ed206f46 src/mem/ruby/buffers/MessageBuffer.hh 3f49ed206f46 src/mem/ruby/buffers/MessageBuffer.cc 3f49ed206f46 src/mem/ruby/buffers/MessageBufferNode.hh 3f49ed206f46 src/mem/ruby/common/Consumer.hh 3f49ed206f46 src/mem/ruby/common/Global.hh 3f49ed206f46 src/mem/ruby/common/TypeDefines.hh 3f49ed206f46 src/mem/ruby/eventqueue/RubyEventQueue.hh 3f49ed206f46 src/mem/ruby/eventqueue/RubyEventQueue.cc 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/InputUnit_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/OutVcState_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/VirtualChannel_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/flit_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/FlexibleConsumer.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/InVcState.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/InVcState.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/NetworkLink.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/NetworkLink.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/OutVcState.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/OutVcState.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/Router.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/Router.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/flit.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/flit.cc 3f49ed206f46 src/mem/ruby/network/simple/Throttle.hh 3f49ed206f46 src/mem/ruby/profiler/Profiler.hh 3f49ed206f46 src/mem/ruby/profiler/Profiler.cc 3f49ed206f46 src/mem/ruby/profiler/StoreTrace.hh 3f49ed206f46
Re: [m5-dev] Review Request: ruby-stats: support for dump_stats instruction
On 2011-05-03 17:45:41, Brad Beckmann wrote: Can we change the name of Time in base/time.hh instead of Time in Ruby? Right now this patch touches 50+ Ruby files and a bunch of lines within those files just to change Time to RTime. It seems that far fewer changes would be required to change the name of base/time.hh's version of Time. Nathan Binkert wrote: While I wouldn't be opposed to changing the time in base/time.hh if we needed both, but don't we need to move ruby away from its own version of Time anyway? Shouldn't we be using Tick? Also, we've generally never shied away from changes that can be done with a one line sed/perl script. I was about to say something along these lines. This would be a good chance to consolidate Ruby and M5 systems a little. It might be a good idea to do the simple find/replace change on its own so the non-simple non-find/replace stuff doesn't get lost as noise. I don't have deep feelings one way or the other, though. - Gabe --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/675/#review1195 --- On 2011-05-03 11:20:58, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/675/ --- (Updated 2011-05-03 11:20:58) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- ruby-stats: support for dump_stats instruction *** NOTE: The core changes for this diff are in Profiler.cc/hh, stat_control.hh/cc, and pseudo_inst.cc This is a first pass toward getting dump-stats functionality to work cleanly for Ruby. As is, the patch works, but there needs to be discussion over: - Changing Ruby typedef Time to RTime because it conflicts with the Time class defined in base/time.hh (The majority of files are renames)... Is there a better name than RTime? - Where is the right place for this RubyStatEvent code? I hesitated to do any real cosmetic changes because of what impending stat changes might do. I have two thoughts: (1) If Ruby Stats will be registered like old M5 stats, then this code would nicely fold into the old statEvent code in sim_control.cc. Fold into maybe too strong of a phrase even, as most of it should just naturally work. (2) If Ruby Stats are not registered, then maybe placing this code into the RubySystem class. I realized late that the Profiler and Network have two different stats that they track so the RubySystem would be the right place along with calling the namespace RubyStats. Diffs - SConstruct 3f49ed206f46 src/cpu/testers/rubytest/RubyTester.hh 3f49ed206f46 src/cpu/testers/rubytest/RubyTester.cc 3f49ed206f46 src/mem/ruby/buffers/MessageBuffer.hh 3f49ed206f46 src/mem/ruby/buffers/MessageBuffer.cc 3f49ed206f46 src/mem/ruby/buffers/MessageBufferNode.hh 3f49ed206f46 src/mem/ruby/common/Consumer.hh 3f49ed206f46 src/mem/ruby/common/Global.hh 3f49ed206f46 src/mem/ruby/common/TypeDefines.hh 3f49ed206f46 src/mem/ruby/eventqueue/RubyEventQueue.hh 3f49ed206f46 src/mem/ruby/eventqueue/RubyEventQueue.cc 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/InputUnit_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/OutVcState_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/VirtualChannel_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/fixed-pipeline/flit_d.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/FlexibleConsumer.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/GarnetNetwork.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/InVcState.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/InVcState.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/NetworkLink.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/NetworkLink.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/OutVcState.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/OutVcState.cc 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/Router.hh 3f49ed206f46 src/mem/ruby/network/garnet/flexible-pipeline/Router.cc 3f49ed206f46
Re: [m5-dev] Review Request: ruby-stats: support for dump_stats instruction
On 2011-05-03 17:45:41, Brad Beckmann wrote: Can we change the name of Time in base/time.hh instead of Time in Ruby? Right now this patch touches 50+ Ruby files and a bunch of lines within those files just to change Time to RTime. It seems that far fewer changes would be required to change the name of base/time.hh's version of Time. Nathan Binkert wrote: While I wouldn't be opposed to changing the time in base/time.hh if we needed both, but don't we need to move ruby away from its own version of Time anyway? Shouldn't we be using Tick? Also, we've generally never shied away from changes that can be done with a one line sed/perl script. Gabe Black wrote: I was about to say something along these lines. This would be a good chance to consolidate Ruby and M5 systems a little. It might be a good idea to do the simple find/replace change on its own so the non-simple non-find/replace stuff doesn't get lost as noise. I don't have deep feelings one way or the other, though. This should be two diffs: 1 for rename and 1 for stat code. But since they are related to getting dumpstats working I combined them both for the sake of discussion. Time isnt equivalent Tick or I would've happily made that change :). Time is really the Ruby Cycle count so if you change it to Tick then all over the place you would have to convert to cycles when making comparisons for request latencies and various parameters in Ruby. In the interim, maybe changing Time to Cycle would work. Alternatively, you could change Time to Tick, and then force all the latencies throughout Ruby to be expressed in Ticks. This would have the nice effect of setting the latencies for Caches and memory objects with a real time (e.g. 1ns) instead of relative time (e.g. 1 cycle). On 2011-05-03 17:45:41, Brad Beckmann wrote: src/mem/ruby/system/System.hh, line 93 http://reviews.m5sim.org/r/675/diff/1/?file=12399#file12399line93 Why does this need to be static? I think we want to avoid making it more difficult to run Ruby in a multiple system scenario. The network and tracer objects are already static in the system class, so at the time it made sense to make this static as well, since there will only ever be 1 profiler even in the multiple systems case (even in multiple systems, right?) Also, I cant remember the exact scenario, but there was wierdness with grabbing the Profiler pointer in the schedProfileEvent function, and I believe that was because you didnt have an instance of a Profiler object which can be resolved by making that a static variable. That's worth a revisit. On 2011-05-03 17:45:41, Brad Beckmann wrote: src/mem/ruby/profiler/Profiler.cc, line 751 http://reviews.m5sim.org/r/675/diff/1/?file=12380#file12380line751 Why do you have to create a separate namespace here? Relic from mimicking the old schedStatEvent function and when I thought that the Profiler was the only place that cared about stats (the Network does too). I suppose placing all the code in RubySystem and then accessing things using RubySystem::function() would work just as well. But again, a lot of this stats stuff would be solved if Ruby registered stats similar to the way M5 does. On 2011-05-03 17:45:41, Brad Beckmann wrote: src/sim/pseudo_inst.cc, line 75 http://reviews.m5sim.org/r/675/diff/1/?file=12404#file12404line75 Why is the RUBY compile flag necessary? If Ruby isn't compiled in, then calling RubyProfile::function wouldnt compile correctly as none of the Ruby code would be recognized. - Korey --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/675/#review1195 --- On 2011-05-03 11:20:58, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/675/ --- (Updated 2011-05-03 11:20:58) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- ruby-stats: support for dump_stats instruction *** NOTE: The core changes for this diff are in Profiler.cc/hh, stat_control.hh/cc, and pseudo_inst.cc This is a first pass toward getting dump-stats functionality to work cleanly for Ruby. As is, the patch works, but there needs to be discussion over: - Changing Ruby typedef Time to RTime because it conflicts with the Time class defined in base/time.hh (The majority of files are renames)... Is there a better name than RTime? - Where is the right place for this RubyStatEvent code? I hesitated to do any real cosmetic changes because of what impending stat changes might do. I have two thoughts: (1) If Ruby Stats will be registered like old M5 stats, then
[m5-dev] Review Request: ruby: use RubyMemory flag remove setDebug() functionality
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/676/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- ruby: use RubyMemory flag remove setDebug() functionality The RubyMemory flag wasnt used in the code, creating large gaps in trace output. Replace cprintfs w/dprintfs using RubyMemory in memory controller. DPRINTF also deprecate the usage of the setDebug() pure virtual function in the AbstractMemoryOrCache Class as well the m_debug/cprintf functions in MemoryControl.hh/cc Diffs - src/mem/ruby/system/AbstractMemOrCache.hh 3f49ed206f46 src/mem/ruby/system/MemoryControl.hh 3f49ed206f46 src/mem/ruby/system/MemoryControl.cc 3f49ed206f46 Diff: http://reviews.m5sim.org/r/676/diff Testing --- Thanks, Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: CPU: Add some useful debug message to the timing simple cpu.
On 2011-05-02 16:54:31, Gabe Black wrote: Generally speaking, I'd like to see us move towards using the same traceflags across ISAs and CPUs. If I'm using the SimpleCPU, being able to select DPRINTFs specific to the SimpleCPU isn't that useful. I'm not going to hit an O3 DPRINTF whether I have them turned on or not. Instead, it might be better to, say, use a Fetch traceflag to go with Fetch actions. Then you can be more specific and have to remember fewer particulars of the thing you're working with. You could have a compound traceflag called SimpleCPU (or just CPU?) which would turn on all the basics. It might get a little tricky if you have multiple CPU types and wanted to turn on only the ones in the SimpleCPU, but I expect that to be relatively uncommon. I'd encourage you to think about changing things around like this, but I understand it expands the scope of what you were trying to do significantly. I'm ok if you leave it as is. I'm on board with having traceflags mean the same across CPU models. The answer to this is to have compound trace flags be able to contain other compound trace flags. (Nate says his new changes will allow this, so cross your fingers!) If you do this, then that means we can define the Fetch traceflag to mean: Fetch: SimpleCPUFetch,O3Fetch,InOrderFetch and then the CPU models can define what are the relevant flags appropriately. - Korey --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/671/#review1184 --- On 2011-05-02 15:41:50, Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/671/ --- (Updated 2011-05-02 15:41:50) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- CPU: Add some useful debug message to the timing simple cpu. Diffs - src/cpu/simple/timing.cc 3f49ed206f46 Diff: http://reviews.m5sim.org/r/671/diff Testing --- Thanks, Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: CPU: Add some useful debug message to the timing simple cpu.
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/671/#review1201 --- Ship it! I'd love the compound trace flags and consolidation of flags across models but until that happens...Ship! - Korey On 2011-05-02 15:41:50, Ali Saidi wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/671/ --- (Updated 2011-05-02 15:41:50) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- CPU: Add some useful debug message to the timing simple cpu. Diffs - src/cpu/simple/timing.cc 3f49ed206f46 Diff: http://reviews.m5sim.org/r/671/diff Testing --- Thanks, Ali ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
