sanchayanmaity/gem5
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Ruby: Fix RubyPort evict packet memory leak

Browse source 
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.
This commit is contained in:
Joel Hestness 2013-04-09 16:25:30 -05:00
parent 46d4b71aa2
commit 1583056de8
1 changed files with 9 additions and 4 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

13
src/mem/ruby/system/RubyPort.cc
View file

@ -496,14 +496,19 @@ void
RubyPort::ruby_eviction_callback(const Address& address)
{
DPRINTF(RubyPort, "Sending invalidations.\n");
// should this really be using funcMasterId?
Request req(address.getAddress(), 0, 0, Request::funcMasterId);
// This request is deleted in the stack-allocated packet destructor
// when this function exits
// TODO: should this really be using funcMasterId?
RequestPtr req =
new Request(address.getAddress(), 0, 0, Request::funcMasterId);
// Use a single packet to signal all snooping ports of the invalidation.
// This assumes that snooping ports do NOT modify the packet/request
Packet pkt(req, MemCmd::InvalidationReq);
for (CpuPortIter p = slave_ports.begin(); p != slave_ports.end(); ++p) {
// check if the connected master port is snooping
if ((*p)->isSnooping()) {
Packet *pkt = new Packet(&req, MemCmd::InvalidationReq);
// send as a snoop request
(*p)->sendTimingSnoopReq(pkt);
(*p)->sendTimingSnoopReq(&pkt);
}
}
}