----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2499/#review5560 -----------------------------------------------------------
Ship it! Just minor comment-related stuff, no need to repost. src/mem/cache/mshr.cc <http://reviews.gem5.org/r/2499/#comment4999> shouldn't this comment go above the constructor call? src/mem/packet.hh <http://reviews.gem5.org/r/2499/#comment4984> 'whenever' src/mem/packet.hh <http://reviews.gem5.org/r/2499/#comment4985> 'allocate' - Steve Reinhardt On Nov. 26, 2014, 2:05 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2499/ > ----------------------------------------------------------- > > (Updated Nov. 26, 2014, 2:05 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10572:ca0ba71c37f9 > --------------------------- > 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 dd04eb06ad42 > src/mem/cache/mshr.cc dd04eb06ad42 > src/mem/packet.hh dd04eb06ad42 > > 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
