> On Sept. 12, 2015, 1:54 p.m., Andreas Hansson wrote: > > My comment seems to have gotten lost in all the different threads going > > on...bad S/N. Anyways, here it is: > > > > I am of the opinion that we should probably 1) do read/write combining in > > the core LSQ before sending out a packet, and 2) combining of MSHR targets > > in the L1 before propagating a miss downwards. I am not sure why we would > > ever do it in the Sequencer. Am I missing something? > > > > This solution would also translate very well between both Ruby and the > > classic memory system. > > Joel Hestness wrote: > Hi Andreas. I think we all agree with you about where coalescing should > happen. It appears that (1) is available from particular cores (e.g. the O3 > CPU). The problem currently is that getting (2) in Ruby would require very > non-trivial modification to the L1 controllers (to do combining) in each of > the existing protocols (7 in gem5 + at least 2 not yet in gem5). To avoid all > this protocol modification, this patch is AMD's proposal to do L1 MSHR-like > combining within the sequencer. This proposed solution should be viewed as a > stopgap on the road to MSHR combining in the L1 controllers. > > Andreas Hansson wrote: > I see. Thanks for the clarification. > > I am fairly convinced the O3 CPU is not doing any coalescing at the > moment. Are you sure? If not I'd say that's the place to start. Coalescing in > the LSQ is probably as important as coalescing of MSHR targets, if not more > so.
Sorry. Inspecting the O3 LSQ code, I believe you are correct that it does not do any coalescing. - Joel ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2787/#review7166 ----------------------------------------------------------- On July 22, 2015, 6:15 p.m., Tony Gutierrez wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2787/ > ----------------------------------------------------------- > > (Updated July 22, 2015, 6:15 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10887:1e05089bc991 > --------------------------- > ruby: Fixed pipeline squashes caused by aliased requests > > This patch was created by Bihn Pham during his internship at AMD. > > This patch fixes a very significant performance bug when using the O3 CPU > model > and Ruby. The issue was Ruby returned false when it received a request to the > same address that already has an outstanding request or when the memory is > blocked. As a result, O3 unnecessary squashed the pipeline and re-executed > instructions. This fix merges readRequestTable and writeRequestTable in > Sequencer into a single request table that keeps track of all requests and > allows multiple outstanding requests to the same address. This prevents O3 > from squashing the pipeline. > > > Diffs > ----- > > src/mem/ruby/system/Sequencer.hh ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/system/Sequencer.cc ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > src/mem/ruby/system/Sequencer.py ebb3d0737aa72ec4fa24b6af9cf9a6b2a1109d18 > > Diff: http://reviews.gem5.org/r/2787/diff/ > > > Testing > ------- > > > Thanks, > > Tony Gutierrez > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
