> On July 23, 2015, 10:01 p.m., Tony Gutierrez wrote: > > This patch seems ok, but can you hold off on pushing this and other ruby > > related changes until we push our patches. We plan to ship our patches by > > next Friday (07/31).
I also feel that these changes are ok. The sender and receiver pointers are a bit strange for MessageBuffers, so I support removing them. I suspect there will be merging headaches with the MessageBuffers->SimObjects patch (2845: http://reviews.gem5.org/r/2845/), and I'm hoping we can resolve a reasonable agreement on push order. AMD has given close-to-final feedback on 2845, but I haven't heard from you, Nilay. Would you be ok waiting on this patch until 2845 is in? - Joel ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2985/#review6820 ----------------------------------------------------------- On July 21, 2015, 3:28 p.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2985/ > ----------------------------------------------------------- > > (Updated July 21, 2015, 3:28 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10947:f66800e62c22 > --------------------------- > ruby: message buffer, timer table: significant changes > > This patch changes MessageBuffer and TimerTable, two structures used for > buffering messages by components in ruby. These structures would no longer > maintain pointers to clock objects. Functions in these structures have been > changed to take as input current time in Tick. Similarly, these structures > will not operate on Cycle valued latencies for different operations. The > corresponding functions would need to be provided with these latencies by > components invoking the relevant functions. These latencies should also be > in Ticks. > > I felt the need for these changes while trying to speed up ruby. The ultimate > aim is to eliminate Consumer class and replace it with an EventManager object > in > the MessageBuffer and TimerTable classes. This object would be used for > scheduling events. The event itself would contain information on the object > and > function to be invoked. > > In hindsight, it seems I should have done this while I was moving away from > use > of a single global clock in the memory system. That change led to > introduction > of clock objects that replaced the global clock object. It never crossed my > mind that having clock object pointers is not a good design. And now I really > don't like the fact that we have separate consumer, receiver and sender > pointers in message buffers. > > > Diffs > ----- > > src/mem/protocol/MESI_Three_Level-L0cache.sm f48e72961850 > src/mem/protocol/MESI_Three_Level-L1cache.sm f48e72961850 > src/mem/protocol/MESI_Two_Level-L1cache.sm f48e72961850 > src/mem/protocol/MESI_Two_Level-L2cache.sm f48e72961850 > src/mem/protocol/MESI_Two_Level-dir.sm f48e72961850 > src/mem/protocol/MESI_Two_Level-dma.sm f48e72961850 > src/mem/protocol/MI_example-cache.sm f48e72961850 > src/mem/protocol/MI_example-dir.sm f48e72961850 > src/mem/protocol/MI_example-dma.sm f48e72961850 > src/mem/protocol/MOESI_CMP_directory-L1cache.sm f48e72961850 > src/mem/protocol/MOESI_CMP_directory-L2cache.sm f48e72961850 > src/mem/protocol/MOESI_CMP_directory-dir.sm f48e72961850 > src/mem/protocol/MOESI_CMP_directory-dma.sm f48e72961850 > src/mem/protocol/MOESI_CMP_token-L1cache.sm f48e72961850 > src/mem/protocol/MOESI_CMP_token-L2cache.sm f48e72961850 > src/mem/protocol/MOESI_CMP_token-dir.sm f48e72961850 > src/mem/protocol/MOESI_CMP_token-dma.sm f48e72961850 > src/mem/protocol/MOESI_hammer-cache.sm f48e72961850 > src/mem/protocol/MOESI_hammer-dir.sm f48e72961850 > src/mem/protocol/MOESI_hammer-dma.sm f48e72961850 > src/mem/protocol/Network_test-cache.sm f48e72961850 > src/mem/protocol/Network_test-dir.sm f48e72961850 > src/mem/protocol/RubySlicc_Exports.sm f48e72961850 > src/mem/protocol/RubySlicc_Types.sm f48e72961850 > src/mem/ruby/network/MessageBuffer.hh f48e72961850 > src/mem/ruby/network/MessageBuffer.cc f48e72961850 > src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.cc > f48e72961850 > src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc > f48e72961850 > src/mem/ruby/network/simple/PerfectSwitch.cc f48e72961850 > src/mem/ruby/network/simple/Switch.cc f48e72961850 > src/mem/ruby/network/simple/Throttle.cc f48e72961850 > src/mem/ruby/slicc_interface/AbstractController.hh f48e72961850 > src/mem/ruby/slicc_interface/AbstractController.cc f48e72961850 > src/mem/ruby/slicc_interface/Controller.py f48e72961850 > src/mem/ruby/structures/TBETable.hh f48e72961850 > src/mem/ruby/structures/TimerTable.hh f48e72961850 > src/mem/ruby/structures/TimerTable.cc f48e72961850 > src/mem/ruby/system/DMASequencer.cc f48e72961850 > src/mem/ruby/system/RubyPort.cc f48e72961850 > src/mem/ruby/system/Sequencer.cc f48e72961850 > src/mem/slicc/ast/EnqueueStatementAST.py f48e72961850 > src/mem/slicc/ast/PeekStatementAST.py f48e72961850 > src/mem/slicc/ast/StallAndWaitStatementAST.py f48e72961850 > src/mem/slicc/symbols/StateMachine.py f48e72961850 > > Diff: http://reviews.gem5.org/r/2985/diff/ > > > Testing > ------- > > > Thanks, > > Nilay Vaish > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
