----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/408/#review797 -----------------------------------------------------------
I was thinking about why the ratio of number of memory lookups, as reported by gprof, and the number of memory references, as reported in stats.txt. While I was working with the MESI CMP directory protocol, I had seen that the same request from the processor is looked up again and again in the cache, if the request is waiting for some event to happen. For example, suppose a processor asks for loading address A, but the cache has no space for holding address A. Then, it will give up some cache block B before it can bring in address A. The problem is that while the cache block B is being given, it is possible that the request made for address A is looked up in the cache again, even though we know it is not possible that we would find it in the cache. This is because the requests in the mandatory queue are recycled till they get done with. Clearly, we should remove the request for bringing in address A to a separate structure, instead of looking it up again and again. The new structure should be looked up whenever an event, that could possibly affect the status of this request, occurs. If we do this, then I think we should see a further reduction in the number of lookups. I would expect almost 90% of the lookups to the cache to go away. This should also mean a 5% improvement in simulator performance. Brad, do agree with the above reasoning? If I am reading the patch correctly, I think this patch is trying to do that, though I do not see the mandatory queue being popped. Can you explain the purpose of the patch in a slightly verbose manner? If it is doing doing what I said above, then I think we should do this for all the protocols. - Nilay On 2011-01-06 16:19:46, Brad Beckmann wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/408/ > ----------------------------------------------------------- > > (Updated 2011-01-06 16:19:46) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > ------- > > ruby: support to stallAndWait the mandatory queue > > By stalling and waiting the mandatory queue instead of recycling it, one can > ensure that no incoming messages are starved when the mandatory queue puts > signficant of pressure on the L1 cache controller (i.e. the ruby memtester). > > > Diffs > ----- > > src/mem/protocol/MOESI_CMP_token-L1cache.sm 9f9e10967912 > src/mem/protocol/MOESI_hammer-cache.sm 9f9e10967912 > src/mem/ruby/buffers/MessageBuffer.hh 9f9e10967912 > src/mem/ruby/buffers/MessageBuffer.cc 9f9e10967912 > src/mem/slicc/ast/WakeUpAllDependentsStatementAST.py PRE-CREATION > src/mem/slicc/ast/__init__.py 9f9e10967912 > src/mem/slicc/parser.py 9f9e10967912 > src/mem/slicc/symbols/StateMachine.py 9f9e10967912 > > Diff: http://reviews.m5sim.org/r/408/diff > > > Testing > ------- > > > Thanks, > > Brad > >
_______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
