Hi Nilay, Did you discard this patch? I cannot see it on reviewboard. I did not get a chance to see it, but it sounds like a substantial change. Before you spend any more time on it, we should probably discuss the long-term direction here and make sure we are all aligned.
Thanks, Brad -----Original Message----- From: gem5-dev [mailto:[email protected]] On Behalf Of Nilay Vaish Sent: Friday, August 14, 2015 8:57 PM To: Nilay Vaish; Default Subject: [gem5-dev] Review Request 3043: ruby: combine RubyPort and Sequencer and rename as FirstLevelController ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3043/ ----------------------------------------------------------- Review request for Default. Repository: gem5 Description ------- Changeset 11069:d415555504b9 --------------------------- ruby: combine RubyPort and Sequencer and rename as FirstLevelController This patch move the file RubyPort.* to FirstLevelController.*. Then, it copies the contents of Sequencer.* to FirstLevelController.*. Finally, it renames RubyPort and Sequencer to FirstLevelController and adjusts line lengths where ever execeeded. There are two reasons for this change: * I find this FirstLevelController abstraction better than having separate RubyPort and Sequencer. With the FirstLevelController class, we are trying to imply the functionality is common to all controllers that are directly attached to the cores. Earlier, it appeared as if there are two components between the core and the actual first level controller. Now the first level controllers in slicc would inherit from this new FirstLevelController class and we would directly connect the controller to the core, instead of going through the sequencer. * The combined entity would allow us to make some changes that would ultimately improve ruby's performance significantly. Now some thoughts on what lies ahead. After this patch, we would create two separate paths for processing of packets in the ruby memory system. One is similar to the current path: the packets would be received by the FirstLevelController, which would carry out the same functionality that RubyPort and Sequencer used to carry out earlier. We would convert packet to RubyRequest and store the packet in the FirstLevelController, encapsulated in a SequencerRequest which is kept in a hash map. When the request gets fullfilled, the reply would be processed as before. The second path would process the packet as the erstwhile RubyPort used to do and hand it to the controller defined in SLICC. The controller would directly work with the packet, so no RubyRequest or SequencerRequest would be created and no hash map insertion/lookups/deletions would happen. In the common case of hits, the packet would be returned immediately. On a miss the TBE would hold the packet till the request gets fullfilled. Actually, the TBEs would now have a vector<Packet *> so that they can coalesce multiple requests for the same block. I would make the protocol changes only to MESI Two Level and Three Level protocols. For the rest we would continue using the original path. The changes to protocols using the original path would kept as low as possible, with the intention being absolutely no changes. It is expected that we would see considerable performance improvement for protocols using the new path. It is already known that we would see about 6% performance improvement by dropping RubyRequest and SequencerRequest. Avoiding hashmap would provide us further improvements. While I have not given this much thought, but we might ultimately be able to work with ports in controllers written in SLICC. Doing so would avoid the extra queueing cost that we currently pay when we pick packets from ports and queue them in the first level controller's mandatory queue. Diffs ----- configs/example/fs.py 110cce93d398 configs/ruby/MESI_Two_Level.py 110cce93d398 src/mem/ruby/system/System.cc 110cce93d398 src/mem/slicc/symbols/StateMachine.py 110cce93d398 tests/configs/pc-simple-timing-ruby.py 110cce93d398 src/mem/ruby/profiler/Profiler.cc 110cce93d398 src/mem/ruby/slicc_interface/AbstractController.hh 110cce93d398 src/mem/ruby/slicc_interface/AbstractController.cc 110cce93d398 src/mem/ruby/slicc_interface/AbstractDMAController.hh PRE-CREATION src/mem/ruby/slicc_interface/AbstractDMAController.cc PRE-CREATION src/mem/ruby/slicc_interface/Controller.py 110cce93d398 src/mem/ruby/slicc_interface/FirstLevelController.hh PRE-CREATION src/mem/ruby/slicc_interface/FirstLevelController.cc PRE-CREATION src/mem/ruby/slicc_interface/SConscript 110cce93d398 src/mem/ruby/system/CacheRecorder.hh 110cce93d398 src/mem/ruby/system/CacheRecorder.cc 110cce93d398 src/mem/ruby/system/DMASequencer.hh 110cce93d398 src/mem/ruby/system/DMASequencer.cc 110cce93d398 src/mem/ruby/system/RubyPort.hh 110cce93d398 src/mem/ruby/system/RubyPort.cc 110cce93d398 src/mem/ruby/system/RubyPortProxy.hh 110cce93d398 src/mem/ruby/system/RubySystem.py 110cce93d398 src/mem/ruby/system/SConscript 110cce93d398 src/mem/ruby/system/Sequencer.hh 110cce93d398 src/mem/ruby/system/Sequencer.cc 110cce93d398 src/mem/ruby/system/Sequencer.py 110cce93d398 configs/ruby/Ruby.py 110cce93d398 src/mem/protocol/MESI_Two_Level-L1cache.sm 110cce93d398 src/mem/protocol/MESI_Two_Level-dma.sm 110cce93d398 src/mem/protocol/RubySlicc_Exports.sm 110cce93d398 src/mem/protocol/RubySlicc_Types.sm 110cce93d398 src/mem/ruby/SConscript 110cce93d398 src/mem/ruby/network/BasicLink.py 110cce93d398 Diff: http://reviews.gem5.org/r/3043/diff/ Testing ------- Thanks, Nilay Vaish _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
