mem: Don't use hasSharers in the snoopFilter for memory responses
authorNikos Nikoleris <nikos.nikoleris@arm.com>
Mon, 5 Dec 2016 21:48:26 +0000 (16:48 -0500)
committerNikos Nikoleris <nikos.nikoleris@arm.com>
Mon, 5 Dec 2016 21:48:26 +0000 (16:48 -0500)
commit5ebb8ec46b9831f4a519b856f45bd383d0c15724
tree596562fbd4e64c32b54b8ba8edc9362d06c0e359
parent78a97b1847e77a60cf085137a37492a18db2dfb8
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>
src/mem/snoop_filter.cc