summaryrefslogtreecommitdiff
path: root/src/Doxyfile
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/Doxyfile
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/Doxyfile')
0 files changed, 0 insertions, 0 deletions