> On 2011-03-24 08:58:15, Brad Beckmann wrote: > > src/mem/ruby/system/Sequencer.cc, line 396 > > <http://reviews.m5sim.org/r/552/diff/6/?file=11209#file11209line396> > > > > I don't think you need to separately handle Flush request. I believe > > the current implmementation of handleLlsc should always return true for > > Flush requests. Please remove this change.
handleLlsc accesses the cache entry ((m_dataCache_ptr->isLocked(address, m_version)), however in case of cache flushes, we keep the line in TBE and deallocate the cache entry. Therefore, regular implementation of handleLlsc does not work properly with Flush requests (gives an error when it tries to access the cache entry as it does not exist). I can add a condition inside this function to return True for Flush requests, what do you think? > On 2011-03-24 08:58:15, Brad Beckmann wrote: > > src/mem/ruby/system/Sequencer.cc, line 541 > > <http://reviews.m5sim.org/r/552/diff/6/?file=11209#file11209line541> > > > > I thought we concluded that Flush requests can callback the RubyPort? > > As long as needsResponse is set to false, the cpu should never see the > > packet which is what we want. Right now, I think you have a memory leak > > because the Flush packets are never deleted. Please correct me if I'm > > missing something. ruby_hit_callback calls RubyPort::M5Port::hitCallback. Then, as we set accessPhysMem to False for flush requests, it will call pkt->makeResponse(), which should not be called, so its assertion on needsResponse will fail. Should I change this condition (in RubyPort.cc line 365)? - Somayeh ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/552/#review1009 ----------------------------------------------------------- On 2011-03-23 22:28:01, Somayeh Sardashti wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/552/ > ----------------------------------------------------------- > > (Updated 2011-03-23 22:28:01) > > > Review request for Default and Brad Beckmann. > > > Summary > ------- > > my initial implementation of cache flushing > > > Diffs > ----- > > configs/example/ruby_random_test.py baf4b5f6782e > src/cpu/testers/rubytest/Check.hh baf4b5f6782e > src/cpu/testers/rubytest/Check.cc baf4b5f6782e > src/cpu/testers/rubytest/RubyTester.hh baf4b5f6782e > src/cpu/testers/rubytest/RubyTester.cc baf4b5f6782e > src/cpu/testers/rubytest/RubyTester.py baf4b5f6782e > src/mem/packet.hh baf4b5f6782e > src/mem/packet.cc baf4b5f6782e > src/mem/protocol/MOESI_hammer-cache.sm baf4b5f6782e > src/mem/protocol/MOESI_hammer-dir.sm baf4b5f6782e > src/mem/protocol/MOESI_hammer-msg.sm baf4b5f6782e > src/mem/protocol/RubySlicc_Exports.sm baf4b5f6782e > src/mem/ruby/slicc_interface/RubyRequest.hh baf4b5f6782e > src/mem/ruby/slicc_interface/RubyRequest.cc baf4b5f6782e > src/mem/ruby/system/DMASequencer.cc baf4b5f6782e > src/mem/ruby/system/RubyPort.cc baf4b5f6782e > src/mem/ruby/system/Sequencer.cc baf4b5f6782e > > Diff: http://reviews.m5sim.org/r/552/diff > > > Testing > ------- > > This implementation has passed 10,000,000 ruby test cases, and the > MOESI_hammer regression tests. > > > Thanks, > > Somayeh > > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
