> On Nov. 2, 2015, 8:56 p.m., Joel Hestness wrote: > > Please provide a description for this patch. > > Sooraj Puthoor wrote: > This patch is imported from reviewboard and the original patch is > http://reviews.gem5.org/r/2551/.So, would it help if we use the same > description used in that patch for this patch also?
Sure...? All patches need descriptions (see: http://gem5.org/Submitting_Contributions ). Please update this patch's description. > On Nov. 2, 2015, 8:56 p.m., Joel Hestness wrote: > > src/mem/protocol/RubySlicc_Exports.sm, line 189 > > <http://reviews.gem5.org/r/3177/diff/1/?file=50930#file50930line189> > > > > I don't understand the reason for distinguising _wCC types. Should > > L1Cache/L2Cache types not provide cache coherence? > > > > More generally, if we're going to define these statically, we should > > make sure that they are descriptive and provide a fairly complete set of > > machine type names for existing protocols. Can you please update these and > > provide clearer comments as appropriate? > > Sooraj Puthoor wrote: > I do not know the history behind this change. This is originally a patch > from Nilay (http://reviews.gem5.org/r/2551) and I think Nilay will be the > best person to answer this question. > > Brad Beckmann wrote: > The wCC names have existed for 10+ years. The CC actually stands for > Cache-to-Cache and was used to identify which responses required > cache-to-cache transfers. Since a remote L1 or L2 cache could respond to a > request, there are separate L1Cache_wCC and L2Cache_wCC. > > The existing comments and type descriptions are already fairly long. Do > we really need to expand them? I think you are being pretty unreasonable > here. > > Nilay Vaish wrote: > In my opinion neither 3176 nor 3177 are required. I have seen the patch > on the gpu model and how it uses MachineType in GPUCoalescer. As and when > AMD breaks that patch into smaller pieces, I'll re-write some portions so > that we do not need any statically defined machine types. If we can pull in the GPU without static MachineTypes, excellent! That's what I'd prefer, so we wouldn't need this patch. If we're going to reintroduce static MachineTypes with this patch, the intended meaning of "_wCC" is currently different than implied in the types' descriptions. This is very confusing. It is very reasonable to ask that these have more precise/accurate descriptions. - Joel ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3177/#review7444 ----------------------------------------------------------- On Oct. 30, 2015, 9:49 p.m., Tony Gutierrez wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3177/ > ----------------------------------------------------------- > > (Updated Oct. 30, 2015, 9:49 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11183:4565e2649f8f > --------------------------- > ruby: imported from reviewboard patch 2551 > > filename temp_nilay_machtype.patch > > > Diffs > ----- > > src/mem/slicc/symbols/Type.py 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 > src/mem/slicc/symbols/SymbolTable.py > 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 > src/mem/slicc/parser.py 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 > src/mem/slicc/ast/MachineAST.py 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 > src/mem/slicc/ast/DeclListAST.py 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 > src/mem/protocol/MESI_Two_Level-L1cache.sm > 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 > src/mem/protocol/MESI_Two_Level-L2cache.sm > 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 > src/mem/protocol/MESI_Two_Level-dir.sm > 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 > src/mem/protocol/MESI_Two_Level-dma.sm > 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 > src/mem/protocol/RubySlicc_Exports.sm > 4daf60db14d794e2344a6c86a93bdd8273bc5bb6 > > Diff: http://reviews.gem5.org/r/3177/diff/ > > > Testing > ------- > > > Thanks, > > Tony Gutierrez > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
