> On Aug. 14, 2015, 8:50 p.m., Joel Hestness wrote: > > Wow... wish I had thought to do this so it could have been checked in with > > the rest of the MessageBuffer SimObject patch. I hope we can get it in soon. > > > > @Brad and/or AMD crew: If you see this review, I'd recommend checking out > > this patch soon, since it could save some time merging with MessageBuffer > > changes I just pushed. > > Brad Beckmann wrote: > Can you explain how this makes it easier to merge with your changes? > > Joel Hestness wrote: > Just so you don't have to merge twice. > > Brad Beckmann wrote: > If we were to wait for this patch, we would have to merge with Nilay Addr > -> addr patch. Those are the types of patches that are a real pain to deal > with. I think you guys overestimate the amount of people-power we have > available to devote to merging.
Brad, I admit that whoever is using ruby and has made edits, would need to devote considerable amount of time and effort to merge with the changes I have made and I am proposing to make. While I do not want to put any unnecessary burden on anyone, I think the effort spent would be worthwile because of two reasons: * first and foremost, the simulation performance would improve. The patches that are currently on the reviewboard would together yield about 25% performance improvement with gem5.prof. I will very soon propose more changes that would further improve the performance. * second, I think these changes make ruby more stable to work with. Most of the aspects that I am trying to work on, we have either not touched upon them at all or we went for solutions that (a) do not scale well with increase in simulated system size, (b) are not general enough. My opinion is that ruby memory system is becoming more coherent in its design choices. - Nilay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3001/#review6958 ----------------------------------------------------------- On Aug. 3, 2015, 12:14 a.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3001/ > ----------------------------------------------------------- > > (Updated Aug. 3, 2015, 12:14 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11016:efd32f38e069 > --------------------------- > ruby: declare all protocol message buffers as parameters > > MessageBuffer is a SimObject now. There were protocols that still declared > some of the message buffers are variables of the controller, but not as input > parameters. Special handling was required for these variables in the SLICC > compiler. This patch changes this. Now all message buffers are declared as > input parameters. > > > Diffs > ----- > > src/mem/protocol/MESI_Three_Level-L0cache.sm a618349a7953 > src/mem/protocol/MESI_Two_Level-L1cache.sm a618349a7953 > src/mem/protocol/MESI_Two_Level-dir.sm a618349a7953 > src/mem/protocol/MESI_Two_Level-dma.sm a618349a7953 > src/mem/protocol/MI_example-cache.sm a618349a7953 > src/mem/protocol/MI_example-dir.sm a618349a7953 > src/mem/protocol/MI_example-dma.sm a618349a7953 > src/mem/protocol/MOESI_CMP_directory-L1cache.sm a618349a7953 > src/mem/protocol/MOESI_CMP_directory-L2cache.sm a618349a7953 > src/mem/protocol/MOESI_CMP_directory-dir.sm a618349a7953 > src/mem/protocol/MOESI_CMP_directory-dma.sm a618349a7953 > src/mem/protocol/MOESI_CMP_token-L1cache.sm a618349a7953 > src/mem/protocol/MOESI_CMP_token-dir.sm a618349a7953 > src/mem/protocol/MOESI_CMP_token-dma.sm a618349a7953 > src/mem/protocol/MOESI_hammer-cache.sm a618349a7953 > src/mem/protocol/MOESI_hammer-dir.sm a618349a7953 > src/mem/protocol/MOESI_hammer-dma.sm a618349a7953 > src/mem/protocol/Network_test-cache.sm a618349a7953 > src/mem/protocol/Network_test-dir.sm a618349a7953 > src/mem/slicc/symbols/StateMachine.py a618349a7953 > > Diff: http://reviews.gem5.org/r/3001/diff/ > > > Testing > ------- > > > Thanks, > > Nilay Vaish > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
