----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2499/#review5540 -----------------------------------------------------------
src/mem/packet.hh <http://reviews.gem5.org/r/2499/#comment4970> We don't need this code. src/mem/packet.hh <http://reviews.gem5.org/r/2499/#comment4972> We need better explanation here. What do you mean by "nature of copying static pointers into forwarded packets"? - Nilay Vaish On Nov. 17, 2014, 6:17 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2499/ > ----------------------------------------------------------- > > (Updated Nov. 17, 2014, 6:17 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10549:f25a54e256d8 > --------------------------- > 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). > > > Diffs > ----- > > src/mem/cache/cache_impl.hh 1a9e235cab09 > src/mem/cache/mshr.cc 1a9e235cab09 > src/mem/packet.hh 1a9e235cab09 > > Diff: http://reviews.gem5.org/r/2499/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
