summaryrefslogtreecommitdiff
path: root/src/mem/snoop_filter.cc
diff options
context:
space:
mode:
authorNikos Nikoleris <nikos.nikoleris@arm.com>2016-12-05 16:48:26 -0500
committerNikos Nikoleris <nikos.nikoleris@arm.com>2016-12-05 16:48:26 -0500
commit5ebb8ec46b9831f4a519b856f45bd383d0c15724 (patch)
tree596562fbd4e64c32b54b8ba8edc9362d06c0e359 /src/mem/snoop_filter.cc
parent78a97b1847e77a60cf085137a37492a18db2dfb8 (diff)
downloadgem5-5ebb8ec46b9831f4a519b856f45bd383d0c15724.tar.xz
mem: Don't use hasSharers in the snoopFilter for memory responses
When the snoopFilter receives a response, it updates its state using the hasSharers flag (indicates whether there are more than one copies of the block in the caches above). The hasSharers flag of the packet was previously populated when the request was traversing and snooping the caches looking for the block. 1) When the response is coming from the memory-side port, its order with respect to other responses is not necessarily preserved (e.g., a request that arrived second to the xbar can get its response first). As a result the snoopFilter might process responses out of order updating its residency information using the non valid hasSharers flag which was populated much earlier. 2) When the response is from an on-chip, the MSHRs preserve a well defined order and the hasSharers flag should contain valid information. This patch changes the snoopFilter by avoiding the hasSharers flag when the response is from the memory-side port. Change-Id: Ib2d22a5b7bf3eccac64445127d2ea20ee74bb25b Reviewed-by: Andreas Hansson <andreas.hansson@arm.com> Reviewed-by: Stephan Diestelhorst <stephan.diestelhorst@arm.com>
Diffstat (limited to 'src/mem/snoop_filter.cc')
-rwxr-xr-xsrc/mem/snoop_filter.cc6
1 files changed, 1 insertions, 5 deletions
diff --git a/src/mem/snoop_filter.cc b/src/mem/snoop_filter.cc
index e4ab1bd27..eb500cf72 100755
--- a/src/mem/snoop_filter.cc
+++ b/src/mem/snoop_filter.cc
@@ -358,11 +358,7 @@ SnoopFilter::updateResponse(const Packet* cpkt, const SlavePort& slave_port)
panic_if(!(sf_item.requested & slave_mask), "SF value %x.%x missing "\
"request bit\n", sf_item.requested, sf_item.holder);
- // Update the residency of the cache line. If the response has no
- // sharers we know that the line has been invalidated in all
- // branches that are not where we are responding to.
- if (!cpkt->hasSharers())
- sf_item.holder = 0;
+ // Update the residency of the cache line.
sf_item.holder |= slave_mask;
sf_item.requested &= ~slave_mask;
assert(sf_item.holder | sf_item.requested);