From: Tiago Muck Date: Mon, 25 Feb 2019 22:20:32 +0000 (-0600) Subject: mem-ruby: Do not change blocked msg enqueue info X-Git-Tag: v19.0.0.0~846 X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=42e55cdafdac41830839ac2584d99a8dd5e3d95e;p=gem5.git 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 Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/18412 Tested-by: kokoro Reviewed-by: Jason Lowe-Power Reviewed-by: Matthew Poremba Maintainer: Jason Lowe-Power --- diff --git a/src/mem/ruby/network/MessageBuffer.cc b/src/mem/ruby/network/MessageBuffer.cc index 560b69c63..03d1bb003 100644 --- a/src/mem/ruby/network/MessageBuffer.cc +++ b/src/mem/ruby/network/MessageBuffer.cc @@ -297,16 +297,18 @@ void MessageBuffer::reanalyzeList(list <, 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()); m_consumer->scheduleEventAbsolute(schdTick); + + DPRINTF(RubyQueue, "Requeue arrival_time: %lld, Message: %s\n", + schdTick, *(m.get())); + lt.pop_front(); } }