tree 61431419bf5023db31da17bd75eea2b8423bbbde
parent b4b487e1ad4c3fa9b6295385a9d9899fb743c788
author Nikos Nikoleris <nikos.nikoleris@arm.com> 1551959281 +0000
committer Nikos Nikoleris <nikos.nikoleris@arm.com> 1556895173 +0000

mem-cache: Mark block as dirty after a SWPrefetchEXResp

This is a workaround for a bug introduced from the change:
59e3585a8 arch-arm: We add PRFM PST instruction for arm
which can cause deadlocks in the memory system.

The design of the classic memory system in gem5 makes the folloing two
assumptions:
* A cache that fetches a block with an intention to modify it, becomes
  the point of ordering and therefore commits to respond to any snoop
  requests [1].
* A cache that fetches an exclusive copy of the block, does so with
  the intention to modify it [2]. Immediately after it receives the
  block, it will write to it and mark it as dirty. As the point of
  ordering, it responds to any outstanding snoops.

The current implementation of prefetch exclusive request breaks the
second assumption. A cache can fetch an exclusive block without an
immediate intention to modify it. If the block is not modified, it
will not be marked as dirty. However, the cache has committed to
respond to outstanding snoops, and if the block is clean it
won't. This can result in deadlocks where a snoop gets stuck waiting
for responses.

One solution (implemented by this patch) is to unconditionally mark
the block dirty when filling due to a prefetch exclusive request.
This makes the PrefetchExReq behave like a WriteReq. However, as it
may mark as dirty a clean block, it creates the requirement for an
uncessary WritebackDirty in the future. In practice, this shouldn't be
a big problem unless the application is unnecessarily using prefetch
exclusive instructions.

Other solutions, would require deeper changes to the design of the
memory system to handle this properly.

[1]: When a cache commits to respond, it "informs" the xbar/PoC (point
of coherence) and the other caches of its intention to respond. As a
result the request will not be send to the main memory.
[2]: In fact the assumption is that in the needsWritable MSHR there is
at least one WriteReq before any snoops from other caches.

Change-Id: I378d3c0dadf25fc52e430b67102347b44d2f18ea
Signed-off-by: Nikos Nikoleris <nikos.nikoleris@arm.com>
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/17729
Reviewed-by: Daniel Carvalho <odanrc@yahoo.com.br>
Tested-by: kokoro <noreply+kokoro@google.com>