> 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.
>
> Somayeh Sardashti wrote:
> 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)?
>
Not exactly, we should change the if (accessPhysMem) else statement in
RubyPort::M5Port::hitCallback, to the following:
if (accessPhysMem) {
ruby_port->physMemPort->sendAtomic(pkt);
} else if (needsResponse) {
pkt->makeResponse();
}
> 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.
>
> Somayeh Sardashti wrote:
> 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?
Ah, I see. Yes, we should add a m_dataCache_ptr->isTagPresent() check before
that m_dataCache_ptr->isLocked(address, m_version) test.
- Brad
-----------------------------------------------------------
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
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
