diff options
author | Andreas Hansson <andreas.hansson@arm.com> | 2014-12-02 06:07:54 -0500 |
---|---|---|
committer | Andreas Hansson <andreas.hansson@arm.com> | 2014-12-02 06:07:54 -0500 |
commit | ea5ccc70417db08379027ca7344e50cba53063dd (patch) | |
tree | db523845787bb9104a8619ececb814156b0054a8 /src/mem/cache/mshr.cc | |
parent | f012166bb600ebaeefa48e74f7dd7fdfc9742506 (diff) | |
download | gem5-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.cc | 6 |
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); |