mem-cache: Avoid promotion of incompatible deferred targets

Often a request that hits on an MSHR has to be deferred as it can't be
serviced by the current response.

For example, a request that requires writable has to be deferred when
the response is expected to bring in a read-only copy of the
block. However, there are cases where the response, although not
expected to do so, brings a writable copy and as a result we also
service deferred targets. In such cases, we promote deferred targets
up until the first that can't be serviced by the current response
(e.g., cache maintainance operation). If the first deferred target is
incompatible we don't promote any targets at all.

Change-Id: Ib3e13be51120b7c0f0053b83b76bde03e1b7dd4e
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/22127
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Jason Lowe-Power <jason@lowepower.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Maintainer: Jason Lowe-Power <jason@lowepower.com>

diff --git a/src/mem/cache/mshr.cc b/src/mem/cache/mshr.cc
index 13a50169c4a7c7c31994221b9c8eaae0720c7f07..4241fa375c86f5a4e9d41137a68c9299f59bfe07 100644 (file)
--- a/src/mem/cache/mshr.cc
+++ b/src/mem/cache/mshr.cc
@@ -612,8 +612,10 @@ MSHR::promoteReadable()
 void
 MSHR::promoteWritable()
 {
+    PacketPtr def_tgt_pkt = deferredTargets.front().pkt;
     if (deferredTargets.needsWritable &&
-        !(hasPostInvalidate() || hasPostDowngrade())) {
+        !(hasPostInvalidate() || hasPostDowngrade()) &&
+        !def_tgt_pkt->req->isCacheInvalidate()) {
         // We got a writable response, but we have deferred targets
         // which are waiting to request a writable copy (not because
         // of a pending invalidate).  This can happen if the original