> On July 13, 2015, 8:16 p.m., Joel Hestness wrote: > > src/mem/protocol/MESI_Three_Level-L0cache.sm, line 147 > > <http://reviews.gem5.org/r/2957/diff/1/?file=47973#file47973line147> > > > > Minor: Convention in other SLICC controller functions is to name > > function arguments using lower_underscore rather than lowerCamelCase.
Will fix this before commit. > On July 13, 2015, 8:16 p.m., Joel Hestness wrote: > > src/mem/protocol/RubySlicc_Types.sm, line 150 > > <http://reviews.gem5.org/r/2957/diff/1/?file=47984#file47984line150> > > > > Minor: Could you use the default parameter specifier here so you could > > avoid passing static 'false' in a few cases? I would really like to do that. The problem is with SLICC. It handles class member functions differently from how it handles stand alone functions. You can specify defaults with stand alone functions but not with member functions. Look at the function MemberMethodCallExprAST::generate_prefix() in file src/mem/slicc/ast/MethodCallExprAST.py. Unless that function is fixed, it is not possible. I have not still not made up my mind on fixing that function. > On July 13, 2015, 8:16 p.m., Joel Hestness wrote: > > src/mem/protocol/MESI_Three_Level-L0cache.sm, line 697 > > <http://reviews.gem5.org/r/2957/diff/1/?file=47973#file47973line697> > > > > Is it necessary to update the replacement policy through an additional > > action like this? This seems pretty fragile if a user forgets to include > > this in transitions analogous to this one. It would also be nice to have a > > single process for updating replacement policy. I don't like doing this either. I am thinking of adding functions that return the set id and way id within a set. The lookup would be done in two steps and replacement policy can be updated by using a version of setMRU that takes set and way as argument. - Nilay ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2957/#review6744 ----------------------------------------------------------- On July 10, 2015, 4:29 p.m., Nilay Vaish wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2957/ > ----------------------------------------------------------- > > (Updated July 10, 2015, 4:29 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10933:184eac6db147 > --------------------------- > ruby: call setMRU from L1 controllers, not from sequencer > Currently the sequencer calls the function setMRU that updates the replacement > policy structures with the first level caches. While functionally this is > correct, the problem is that this requires calling findTagInSet() which is an > expensive function. This patch removes the calls to setMRU from the > sequencer. > The first level controllers shoul now update the replacement policy. If the > access is a cache hit, the function findTagInSet is called only once when the > block is first found (common case). If the access is a miss, then the > controller calls setMRU() just before calling the sequencer for returning the > data. > > > Diffs > ----- > > src/mem/protocol/MESI_Three_Level-L0cache.sm 5c76426fd9ee > src/mem/protocol/MESI_Three_Level-L1cache.sm 5c76426fd9ee > src/mem/protocol/MESI_Two_Level-L1cache.sm 5c76426fd9ee > src/mem/protocol/MESI_Two_Level-L2cache.sm 5c76426fd9ee > src/mem/protocol/MI_example-cache.sm 5c76426fd9ee > src/mem/protocol/MOESI_CMP_directory-L1cache.sm 5c76426fd9ee > src/mem/protocol/MOESI_CMP_directory-L2cache.sm 5c76426fd9ee > src/mem/protocol/MOESI_CMP_token-L1cache.sm 5c76426fd9ee > src/mem/protocol/MOESI_CMP_token-L2cache.sm 5c76426fd9ee > src/mem/protocol/MOESI_hammer-cache.sm 5c76426fd9ee > src/mem/protocol/MOESI_hammer-dir.sm 5c76426fd9ee > src/mem/protocol/RubySlicc_Types.sm 5c76426fd9ee > src/mem/ruby/structures/CacheMemory.hh 5c76426fd9ee > src/mem/ruby/structures/CacheMemory.cc 5c76426fd9ee > src/mem/ruby/system/Sequencer.cc 5c76426fd9ee > > Diff: http://reviews.gem5.org/r/2957/diff/ > > > Testing > ------- > > > Thanks, > > Nilay Vaish > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
