> On April 13, 2016, 7:08 p.m., Joel Hestness wrote: > > configs/ruby/MESI_Three_Level.py, line 153 > > <http://reviews.gem5.org/r/3441/diff/1/?file=54823#file54823line153> > > > > This change connects the L0 caches to the network rather than > > connecting them directly to the L1 caches. Since both are private to the > > connected core, it seems superfluous to run their activity through the > > network; They only communicate with each other through these MessageBuffers. > > > > Is there a bigger need for this that I'm not seeing? > > Brandon Potter wrote: > The simple network works fine as it is without this change. However, > running Garnet causes a problem because the network wants the message buffers > associated with the L0 controllers. It requires the message buffer during > GarnetNetwork_d::init(), otherwise it fails out on the following assert: > > gem5.opt: > build/MESI_Three_Level/mem/ruby/network/garnet/fixed-pipeline/GarnetNetwork_d.cc:82: > virtual void GarnetNetwork_d::init(): Assertion `it != m_toNetQueues.end()\' > failed. > > We exposed the controller to the network to appease Garnet. There might > be another way to solve this problem, but this is my solution. You said that > it was "superfluous" so I'm gathering that it doesn't affect correctness, > right? > > If you fix the enumeration problem, you can probably confirm that Garnet > does not work on the tip of the public repo. I do not think that my other > changes affect it (although I am not %100 sure; were quite a few changes in > my patches). > > Brandon Potter wrote: > Follow up, the Garnet issue is a result of my patches. It's related to > something done in the patches which precede it (probably the component > mapping patches). If you apply L0Cache-enumeration patch on the public > repository by itself, then Garnet works just fine. > > I'll have to figure out what it is in the component mapping changes (or a > different patch) that required this due to the message buffer issue.
I take responsibility for this change. I am the one that suggested it to Brandon. It seemed far easier and elegant than hacking a customized fix in Garnet for this scenario. There is precedent in Ruby to have private L1 to private L2 connections go through the network rather than use direct messagebuffers. I'm not sure if any current gem5 protocols do this prior to Brandon's patch, but there certainly were several GEMS protocols that did so. - Brad ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3441/#review8142 ----------------------------------------------------------- On April 4, 2016, 11:45 p.m., Brandon Potter wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3441/ > ----------------------------------------------------------- > > (Updated April 4, 2016, 11:45 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11443:34fcc3f9f957 > --------------------------- > ruby: fix MESI_Three_Level protocol > > > Diffs > ----- > > configs/ruby/MESI_Three_Level.py cfad34a15729e1d5e096245f5a80ded6e2c379ca > configs/topologies/MeshDirCorners.py > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MESI_Three_Level-L0cache.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MESI_Three_Level-L1cache.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > src/mem/protocol/MESI_Three_Level-msg.sm > cfad34a15729e1d5e096245f5a80ded6e2c379ca > > Diff: http://reviews.gem5.org/r/3441/diff/ > > > Testing > ------- > > > Thanks, > > Brandon Potter > > _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
