mem-ruby: Do not change blocked msg enqueue info

Updating the message counter and enqueue times when adding blocked
messages back to the queue does not make a lot of sense since these
messages are not new arrivals.
More importantly, this may lead to starvation. See the scenario below:

1) Request A for a blocked line X arrives
2) A is handled; X is blocked so A is stalled
3) Request B for X arrives; Reponse for X arrives
4) Response is handled; X unblocked; A added back to the request queue
5) B is handled ahead of A (since A's arrival was updated);
   X may become blocked again

If new requests keep comming for X, A may will be stalled forever.

Change-Id: Icad79f3f716a870e91cb3455437b8b3c35f130ac
Signed-off-by: Tiago Muck <tiago.muck@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18412
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Matthew Poremba <matthew.poremba@amd.com>
Maintainer: Jason Lowe-Power <jason@lowepower.com>

diff --git a/src/mem/ruby/network/MessageBuffer.cc b/src/mem/ruby/network/MessageBuffer.cc
index 560b69c637291005c045653d22aa4543d861abff..03d1bb003b1d5ba16f9c506ad1d9898e6cae4b18 100644 (file)
--- a/src/mem/ruby/network/MessageBuffer.cc
+++ b/src/mem/ruby/network/MessageBuffer.cc
@@ -297,16 +297,18 @@ void
 MessageBuffer::reanalyzeList(list<MsgPtr> &lt, Tick schdTick)
 {
     while (!lt.empty()) {
-        m_msg_counter++;
         MsgPtr m = lt.front();
-        m->setLastEnqueueTime(schdTick);
-        m->setMsgCounter(m_msg_counter);
+        assert(m->getLastEnqueueTime() <= schdTick);
 
         m_prio_heap.push_back(m);
         push_heap(m_prio_heap.begin(), m_prio_heap.end(),
                   greater<MsgPtr>());
 
         m_consumer->scheduleEventAbsolute(schdTick);
+
+        DPRINTF(RubyQueue, "Requeue arrival_time: %lld, Message: %s\n",
+            schdTick, *(m.get()));
+
         lt.pop_front();
     }
 }