> On April 8, 2013, 8:11 a.m., Andreas Hansson wrote: > > src/mem/ruby/system/RubyPort.cc, line 500 > > <http://reviews.gem5.org/r/1813/diff/1/?file=34762#file34762line500> > > > > Could you add a comment that the request does not need a response and > > is thus deleted with the packet. > > > > Also, it would be good to highlight that the same packet (potentially > > altered) is now sent to all the ports and this is making assumptions about > > what they do (or don't do) to it. > > > > Thanks
Added these comments to the patch for checkin - Joel ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1813/#review4214 ----------------------------------------------------------- On April 7, 2013, 8:47 p.m., Joel Hestness wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1813/ > ----------------------------------------------------------- > > (Updated April 7, 2013, 8:47 p.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9630:2ea801a03fa5 > --------------------------- > RubyPort: Fix evict/invalidate packet memory leak > > When using the o3 or inorder CPUs with many Ruby protocols, the caches may > need to forward invalidations to the CPUs. The RubyPort was instantiating a > packet to be sent to the CPUs to signal the eviction, but the packets were > not being freed by the CPUs. Consistent with the classic memory model, stack > allocate the packet and heap allocate the request so on > ruby_eviction_callback() completion, the packet deconstructor is called, and > deletes the request (*Note: stack allocating the request causes double > deletion, since it will be deleted in the packet destructor). This results in > the least memory allocations without memory errors. > > > Diffs > ----- > > src/mem/ruby/system/RubyPort.cc fa31189e1fb5 > > Diff: http://reviews.gem5.org/r/1813/diff/ > > > Testing > ------- > > Long runs with Valgrind and verified that the Ruby transitions that caused > these memory leaks were exercised. Multithreaded benchmarks with elevated > contention witness huge memory consumption decreases. > > > Thanks, > > Joel Hestness > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
