----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1813/#review4214 -----------------------------------------------------------
src/mem/ruby/system/RubyPort.cc <http://reviews.gem5.org/r/1813/#comment3990> 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 - Andreas Hansson 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
