summaryrefslogtreecommitdiff
path: root/src/mem/cache/mshr.cc
diff options
context:
space:
mode:
authorAndreas Hansson <andreas.hansson@arm.com>2014-12-02 06:07:54 -0500
committerAndreas Hansson <andreas.hansson@arm.com>2014-12-02 06:07:54 -0500
commitea5ccc70417db08379027ca7344e50cba53063dd (patch)
treedb523845787bb9104a8619ececb814156b0054a8 /src/mem/cache/mshr.cc
parentf012166bb600ebaeefa48e74f7dd7fdfc9742506 (diff)
downloadgem5-ea5ccc70417db08379027ca7344e50cba53063dd.tar.xz
mem: Clean up packet data allocation
This patch attempts to make the rules for data allocation in the packet explicit, understandable, and easy to verify. The constructor that copies a packet is extended with an additional flag "alloc_data" to enable the call site to explicitly say whether the newly created packet is short-lived (a zero-time snoop), or has an unknown life-time and therefore should allocate its own data (or copy a static pointer in the case of static data). The tricky case is the static data. In essence this is a copy-avoidance scheme where the original source of the request (DMA, CPU etc) does not ask the memory system to return data as part of the packet, but instead provides a pointer, and then the memory system carries this pointer around, and copies the appropriate data to the location itself. Thus any derived packet actually never copies any data. As the original source does not copy any data from the response packet when arriving back at the source, we must maintain the copy of the original pointer to not break the system. We might want to revisit this one day and pay the price for a few extra memcpy invocations. All in all this patch should make it easier to grok what is going on in the memory system and how data is actually copied (or not).
Diffstat (limited to 'src/mem/cache/mshr.cc')
-rw-r--r--src/mem/cache/mshr.cc6
1 files changed, 5 insertions, 1 deletions
diff --git a/src/mem/cache/mshr.cc b/src/mem/cache/mshr.cc
index bc46ed267..e4b62e230 100644
--- a/src/mem/cache/mshr.cc
+++ b/src/mem/cache/mshr.cc
@@ -366,7 +366,11 @@ MSHR::handleSnoop(PacketPtr pkt, Counter _order)
// Actual target device (typ. a memory) will delete the
// packet on reception, so we need to save a copy here.
- PacketPtr cp_pkt = new Packet(pkt, true);
+
+ // Clear flags and also allocate new data as the original
+ // packet data storage may have been deleted by the time we
+ // get to send this packet.
+ PacketPtr cp_pkt = new Packet(pkt, true, true);
targets.add(cp_pkt, curTick(), _order, Target::FromSnoop,
downstreamPending && targets.needsExclusive);