> On Dec. 24, 2015, 12:09 a.m., Steve Reinhardt wrote: > > I'm curious how much this matters... are there a significant number of > > cases right now where we're unnecessarily allocating a data buffer? > > > > My gut reaction is that if we're really looking to defer buffer allocation > > until we really know whether or not it's necessary, then we should just > > wait until setData() and just do the allocation then if needed. (You could > > also conceivably do the allocation in make*Response(), but I see how that > > would be complicated by us calling setData() in satisfyCpuSideRequest() > > before we call make*Response().) If there are really cases where we > > currently call setData() but which should be protected by a > > hasData()/hasRespData() check we could add that inside setData().
It just doesn't feel very sensible to be allocating space for an invalidation or upgrade message. It definitely doesn't have any performance impact. Simply a matter of clarity and good design. Concerning your suggestion of deferring the allocation, I prefer to keep it as is. That way we are as similar as possible to TLM2 and IEEE 1666. It is important that gem5 remains interoperable with SystemC TLM2 and this is one of the assumptions that matches up nicely at the moment. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3259/#review7741 ----------------------------------------------------------- On Dec. 16, 2015, 12:40 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3259/ > ----------------------------------------------------------- > > (Updated Dec. 16, 2015, 12:40 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11281:e01a026a48ad > --------------------------- > mem: Do not allocate space for packet data if not needed > > This patch looks at the request and response command to determine if > either actually has any data payload, and if not, we do not allocate > any space for packet data. > > The only tricky case is where the command type is changed as part of > the MSHR functionality. In these cases where the original packet had > no data, but the new packet does, we need to explicitly call > allocate(). > > > Diffs > ----- > > src/mem/cache/cache.cc a3b41de1c4f1 > src/mem/cache/mshr.cc a3b41de1c4f1 > src/mem/packet.hh a3b41de1c4f1 > > Diff: http://reviews.gem5.org/r/3259/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
