----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1813/#review4209 -----------------------------------------------------------
Ship it! Ship It! - Jason Power 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
