mem-cache: Forward snoops when the cache is not responding
When the MSHR is handling a request that will make the block dirty the
current cache commits respond. When that's not the case the cache
should forward any snoops. This CL fixes MSHR::handleSnoop() to
implement this behavior.
Change-Id: I207e3ca4968fd9528fd4cdbfb3eb95f470b4744d
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/23668
Tested-by: kokoro <noreply+kokoro@google.com>
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
diff --git a/src/mem/cache/mshr.cc b/src/mem/cache/mshr.cc
index 1b21546..00dbe90 100644
--- a/src/mem/cache/mshr.cc
+++ b/src/mem/cache/mshr.cc
@@ -465,6 +465,10 @@
return true;
}
+ // Start by determining if we will eventually respond or not,
+ // matching the conditions checked in Cache::handleSnoop
+ const bool will_respond = isPendingModified() && pkt->needsResponse() &&
+ !pkt->isClean();
if (isPendingModified() || pkt->isInvalidate()) {
// We need to save and replay the packet in two cases:
// 1. We're awaiting a writable copy (Modified or Exclusive),
@@ -474,11 +478,6 @@
// to forward the snoop up the hierarchy after the current
// transaction completes.
- // Start by determining if we will eventually respond or not,
- // matching the conditions checked in Cache::handleSnoop
- bool will_respond = isPendingModified() && pkt->needsResponse() &&
- !pkt->isClean();
-
// The packet we are snooping may be deleted by the time we
// actually process the target, and we consequently need to
// save a copy here. Clear flags and also allocate new data as
@@ -535,7 +534,7 @@
pkt->setHasSharers();
}
- return true;
+ return will_respond;
}
MSHR::TargetList