On Tue, 19 May 2015, Brad Beckmann wrote:
On May 15, 2015, 3:07 p.m., Nilay Vaish wrote:
src/mem/ruby/network/MessageBuffer.cc, line 320
<http://reviews.gem5.org/r/2805/diff/1/?file=45061#file45061line320>
Why is this change right? Why can we move messages from one structure to
another in zero time?
These structures are not meant to model hardware. As the comment
directly above this line states, all stalled messages associated with
this address are put back on the prio heap. It is important that the
reanalyzeList call ensures the consumer is scheduled for the current
cycle so that the previously stalled messages will be observed before
any younger messages that may arrive on the same cycle.
I think the aim of stall and wait functionality was to look beyond the
message that is at the head of the priority queue. While earlier we were
attaching some delay with moving messages around, this patch does away
with that delay. I no longer see the point of moving messages from one
structure to another. I suggest that we remove the whole stall and wait
approach and replace the priority queue in the message buffer with either
std::list or std::set. The code will be way more simple.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
