> On Sept. 16, 2015, 6:14 p.m., Nilay Vaish wrote: > > src/mem/ruby/system/RubyPort.cc, line 523 > > <http://reviews.gem5.org/r/3115/diff/1/?file=49496#file49496line523> > > > > Do we know for sure that the receiving end is not going to delete the > > request?
Yes, there are no instances of recvTimingSnoopReq that delete packets in mainline. This seems to indicate that it is the responsibility of the requester to delete snoop packets/requests. - Joel ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3115/#review7198 ----------------------------------------------------------- On Sept. 16, 2015, 6:06 p.m., Joel Hestness wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3115/ > ----------------------------------------------------------- > > (Updated Sept. 16, 2015, 6:06 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11092:03402924ac1e > --------------------------- > ruby: RubyPort delete snoop requests > > In RubyPort::ruby_eviction_callback, prior changes fixed a memory leak caused > by instantiating separate packets for each port that the eviction was > forwarded > to. That change, however, left the instantiated request to also leak. Delete > the request. > > > Diffs > ----- > > src/mem/ruby/system/RubyPort.cc 62e1504b9c64 > > Diff: http://reviews.gem5.org/r/3115/diff/ > > > Testing > ------- > > Compiled gem5.debug with --without-tcmalloc. Ran large tests with Valgrind. > > > Thanks, > > Joel Hestness > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
