[m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression --scratch all
See /z/m5/regression/regress-2011-03-20-03:00:01 for details. ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Network Tester Patch
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/561/ --- (Updated 2011-03-20 05:11:37.330118) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan Binkert, and Brad Beckmann. Changes --- - Addressed Brad's comments: (1) removed functional ports from testers/networktest; (2) added a precision option to ruby_network_test.py that specifies the number of digits of precision after the decimal point for the injection rate. Also added comment to explain injection rate range. This field is used by networktest.cc when deciding whether or not to generate a packet. [Earlier this precision was hard-coded to 3 digits] - Updated the Network_test-cache.sm file to replace CacheRequestType to RubyRequestType in accordance with recent m5 changes. Summary --- This patch adds the network tester for simple and garnet networks. The tester code is in testers/networktest. The tester can be invoked by configs/example/ruby_network_test.py. A dummy coherence protocol called Network_test is also addded for network-only simulations and testing. The protocol takes in messages from the tester and just pushes them into the network in the appropriate vnet, without storing any state. Diffs (updated) - build_opts/ALPHA_SE_Network_test PRE-CREATION configs/example/ruby_network_test.py PRE-CREATION configs/ruby/Network_test.py PRE-CREATION src/cpu/testers/networktest/NetworkTest.py PRE-CREATION src/cpu/testers/networktest/SConscript PRE-CREATION src/cpu/testers/networktest/networktest.hh PRE-CREATION src/cpu/testers/networktest/networktest.cc PRE-CREATION src/mem/protocol/Network_test-cache.sm PRE-CREATION src/mem/protocol/Network_test-dir.sm PRE-CREATION src/mem/protocol/Network_test-msg.sm PRE-CREATION src/mem/protocol/Network_test.slicc PRE-CREATION src/mem/protocol/SConsopts 89cd8302abd3 src/mem/ruby/network/garnet/BaseGarnetNetwork.hh 89cd8302abd3 src/mem/ruby/network/garnet/BaseGarnetNetwork.cc 89cd8302abd3 src/mem/ruby/network/garnet/BaseGarnetNetwork.py 89cd8302abd3 src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 89cd8302abd3 src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.cc 89cd8302abd3 src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc 89cd8302abd3 src/mem/ruby/system/Sequencer.hh 89cd8302abd3 src/mem/ruby/system/Sequencer.cc 89cd8302abd3 src/mem/ruby/system/Sequencer.py 89cd8302abd3 Diff: http://reviews.m5sim.org/r/561/diff Testing --- Testing done with garnet and simple networks. I will update config assumptions etc on the wiki. Thanks, Tushar ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Network Tester Patch
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/561/ --- (Updated 2011-03-20 05:23:02.880797) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, Nathan Binkert, and Brad Beckmann. Changes --- clearer explanation about injectionrate value in ruby_network_test.py Summary --- This patch adds the network tester for simple and garnet networks. The tester code is in testers/networktest. The tester can be invoked by configs/example/ruby_network_test.py. A dummy coherence protocol called Network_test is also addded for network-only simulations and testing. The protocol takes in messages from the tester and just pushes them into the network in the appropriate vnet, without storing any state. Diffs (updated) - src/mem/ruby/system/Sequencer.py 89cd8302abd3 src/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc 89cd8302abd3 src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.cc 89cd8302abd3 src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc 89cd8302abd3 src/mem/ruby/system/Sequencer.hh 89cd8302abd3 src/mem/ruby/system/Sequencer.cc 89cd8302abd3 src/mem/protocol/Network_test.slicc PRE-CREATION src/mem/protocol/SConsopts 89cd8302abd3 src/mem/ruby/network/garnet/BaseGarnetNetwork.hh 89cd8302abd3 src/mem/ruby/network/garnet/BaseGarnetNetwork.cc 89cd8302abd3 src/mem/ruby/network/garnet/BaseGarnetNetwork.py 89cd8302abd3 src/mem/protocol/Network_test-msg.sm PRE-CREATION src/mem/protocol/Network_test-dir.sm PRE-CREATION src/mem/protocol/Network_test-cache.sm PRE-CREATION src/cpu/testers/networktest/networktest.cc PRE-CREATION src/cpu/testers/networktest/SConscript PRE-CREATION src/cpu/testers/networktest/networktest.hh PRE-CREATION src/cpu/testers/networktest/NetworkTest.py PRE-CREATION configs/ruby/Network_test.py PRE-CREATION build_opts/ALPHA_SE_Network_test PRE-CREATION configs/example/ruby_network_test.py PRE-CREATION Diff: http://reviews.m5sim.org/r/561/diff Testing --- Testing done with garnet and simple networks. I will update config assumptions etc on the wiki. Thanks, Tushar ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: SLICC: Remove WakeUp* import calls from ast/__i...
changeset c1c6f36e118e in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=c1c6f36e118e description: SLICC: Remove WakeUp* import calls from ast/__init__.py I had recently committed a patch that removed the WakeUp*.py files from the slicc/ast directory. I had forgotten to remove the import calls for these files from slicc/ast/__init__.py. This resulted in error while running regressions on zizzer. This patch does the needful. diffstat: src/mem/slicc/ast/__init__.py | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diffs (9 lines): diff -r 89cd8302abd3 -r c1c6f36e118e src/mem/slicc/ast/__init__.py --- a/src/mem/slicc/ast/__init__.py Sat Mar 19 21:13:04 2011 -0700 +++ b/src/mem/slicc/ast/__init__.py Sun Mar 20 09:23:27 2011 -0500 @@ -74,5 +74,3 @@ from slicc.ast.TypeFieldMethodAST import * from slicc.ast.TypeFieldStateAST import * from slicc.ast.VarExprAST import * -from slicc.ast.WakeUpAllDependentsStatementAST import * -from slicc.ast.WakeUpDependentsStatementAST import * ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression --scratch all
I had committed an error in one of the my recent patches. I have committed a patch that should fix this error. -- Nilay On Sun, 20 Mar 2011, Cron Daemon wrote: See /z/m5/regression/regress-2011-03-20-03:00:01 for details. ___ 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] Review Request: Ruby: Remove CacheMsg class from SLICC
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/327/ --- (Updated 2011-03-20 10:53:10.248023) Review request for Default. Summary (updated) --- Ruby: Remove CacheMsg class from SLICC The goal of the patch is to do away with the CacheMsg class currently in use in coherence protocols. In place of CacheMsg, the RubyRequest class will used. This class is already present in slicc_interface/RubyRequest.hh. In fact, objects of class CacheMsg are generated by copying values from a RubyRequest object. Diffs (updated) - src/mem/protocol/MESI_CMP_directory-L1cache.sm c1c6f36e118e src/mem/protocol/MI_example-cache.sm c1c6f36e118e src/mem/protocol/MOESI_CMP_directory-L1cache.sm c1c6f36e118e src/mem/protocol/MOESI_CMP_token-L1cache.sm c1c6f36e118e src/mem/protocol/MOESI_hammer-cache.sm c1c6f36e118e src/mem/protocol/RubySlicc_Exports.sm c1c6f36e118e src/mem/protocol/RubySlicc_Profiler.sm c1c6f36e118e src/mem/protocol/RubySlicc_Types.sm c1c6f36e118e src/mem/ruby/profiler/AddressProfiler.hh c1c6f36e118e src/mem/ruby/profiler/AddressProfiler.cc c1c6f36e118e src/mem/ruby/profiler/Profiler.hh c1c6f36e118e src/mem/ruby/profiler/Profiler.cc c1c6f36e118e src/mem/ruby/recorder/TraceRecord.cc c1c6f36e118e src/mem/ruby/slicc_interface/RubyRequest.hh c1c6f36e118e src/mem/ruby/slicc_interface/RubyRequest.cc c1c6f36e118e src/mem/ruby/slicc_interface/RubySlicc_Profiler_interface.hh c1c6f36e118e src/mem/ruby/slicc_interface/RubySlicc_Util.hh c1c6f36e118e src/mem/ruby/system/CacheMemory.hh c1c6f36e118e src/mem/ruby/system/CacheMemory.cc c1c6f36e118e src/mem/ruby/system/DMASequencer.cc c1c6f36e118e src/mem/ruby/system/RubyPort.cc c1c6f36e118e src/mem/ruby/system/Sequencer.cc c1c6f36e118e Diff: http://reviews.m5sim.org/r/327/diff Testing --- Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC
On Sat, 19 Mar 2011, Nilay Vaish wrote: On Fri, 18 Mar 2011, Lisa Hsu wrote: What's going on with this patch? I don't believe it's been committed but it seems like it should. I've also got some patches waiting behind this because they used to touch CacheMsg and I don't want to mess Nilay up, so I've been waiting to serialize behind this. Lisa Lisa, the original patch was pretty long and after some of the changes that Brad submitted, almost the whole of the patch required rework. I have already committed some parts of the original patch. I have posted two more patches on the review board that cover some more portion of the patch. You can ignore the original patch. Assume that I will not post more patches that touch CacheMsg or related structures apart from the two that I posted 5 minutes ago. -- Nilay Lisa, I have updated the patch. If you want, you can commit your patches before I commit this. Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] Review Request: sim: use nextCycle() for quiesceSkip function
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/603/ --- Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- sim: use nextCycle() for quiesceSkip function the increment of curTick causes some compiler to complain on an assert in the event queue scheduler. Since the code is only scheduling for the next cycle it seems safe to go ahead and just use the cpu's function to trick the compiler. NOTE: this only comes up in opt/debug builds since asserts are taken out of fast Diffs - src/sim/pseudo_inst.cc c1c6f36e118e Diff: http://reviews.m5sim.org/r/603/diff Testing --- This passed the simple-atomic, simple-timing, and o3 regressions tests for ARM_FS. Thanks, Korey ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: cpu: split o3-specific parts out of BaseDynInst
On 2011-03-03 20:41:09, Ali Saidi wrote: Please don't ship this until I have a chance to try it, I just want to make sure it doesn't break ARM_FS/O3. Korey Sewell wrote: Sure, I'd welcome a go of things from some other folks to test if I haven't introduced something quirky. After there is some commentary, I'll make sure to run the full regressions before committing this because as we all know BaseDynInst is a pretty fundamental part of M5. Also, I'll be posting an update to this diff soon that will make the setInt/FloatRegOperand pure virtual (I mistakenly thought those were templated member functions in the first go-round). Ali Saidi wrote: Anything happen with your update diff? If you could verify it passes the arm/o3 full system regression I just committed and then I'll give it a go on a bunch more tests. Korey Sewell wrote: Gabe made a good point about the virtual function overhead on the commonly used set*Operand functions and I've just been waffling on whether to even make those pure virtual or not. However, I'll go ahead and take a hard look at this again , run the regressions, and post an update tomorrow so we can move on with this potential change. Korey Sewell wrote: The ARM regressions pass with this patch. Feel free to do further testing. Ali Saidi wrote: What about the virtual function overhead? This patch I posted didn't have any virtual functions in it. I was speculating whether or not we should add the pure virtual functions to solidify the DynInst interface. I went ahead and added the virtual functions in a separate patch, ran the ARM_FS o3 regressions 2x on the same machine, and then took the inst/second from the generated m5 stat files: o3-timing (current): 115133, 115406 o3-timing (this patch): 115011, 115709 o3-timing (this patch w/pure virtual functions on BaseDynInst read/set*Operands): 114368,113055 Although running something 2x isn't anything that could be called thorough, it looks like adding the virtual functions incurs a overhead of about 1K-2K inst/second, while the patch as currently constructed gives about the same performance as the code that doesn't split the o3-specific code out of BaseDynInst. Since few people actually work on the internals of the CPU models anyway, it's probably better to go with the patch submitted (pending further ARM-FS testing) than to sacrifice the small amount of performance for an interface that would rarely, if ever, be extended past the Inorder/O3 models. - Korey --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/529/#review932 --- On 2011-03-01 13:49:24, Korey Sewell wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/529/ --- (Updated 2011-03-01 13:49:24) Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and Nathan Binkert. Summary --- cpu: split o3-specific parts out of BaseDynInst The bigger picture goal is that I want to get the InorderDynInst class derived from the BaseDynInst, since there is no need to replicate a lot of useful code already defined in BaseDynInst (e.g. microcode identification, etc.) and Inorder can take advantage of common code that handles microcode and other features that other ISAs need. But to do this, there are a lot of o3-specific things that are in BaseDynInst, that I pushed to O3DynInst in this patch. Book-keeping variables that handle the IQ,LSQ,ROB are unnecessary in the base class but generic variables that will work across CPUs (IsSquashed, IsCompleted, etc.) are kept in the base class. The upside is more consistency across the simple models (branch prediction and instruction identification are all in one common place). I really wanted to define pure virtual functions for read/write(to memory) and the setInt/FloatRegOperand, but virtual functions in a templated class is a no-no and I couldn't get around that (suggestions?). Also, I'd rather not use the this- pointer all over the place to access member variables of the templated Base class, but it had to be done. Other than those quirks, simulator functionality should stay the same as the O3 Model always references the O3DynInst pointer and the InOrder model doesnt currently make use of the base dyn inst. class. (but it will be easier to derive from now...) Diffs - src/cpu/base_dyn_inst.hh cf1afc88070f src/cpu/base_dyn_inst_impl.hh cf1afc88070f src/cpu/o3/dyn_inst.hh cf1afc88070f src/cpu/o3/dyn_inst_impl.hh cf1afc88070f Diff: http://reviews.m5sim.org/r/529/diff Testing --- Thanks, Korey
