Hi Andreas, The rule is that the final target of a packet gets ownership of the packet and is responsible for deleting it (or optionally reusing it for the response). It is free to delete the packet as soon as it is received. Note that this is independent of which object actually responds. Any other object that wants to hang on to a copy of the packet after the packet has been transmitted needs to make a copy (as you can see often happens with snooping... if another cache needs to hold on to a packet to defer the snoop operation, it must make a copy).
Objects like bridges that merely forward targets to their final destination typically do not need to allocate or deallocate packets. Intermediate caches typically create new packets for miss requests, so the initial request packet from the CPU side and the resulting miss packets are treated independently as far as allocation and deallocation (though obviously the lifetimes are related). Of course all of this discussion is with respect to the classic M5 memory system; internal Ruby messages are a different story (that I don't know off the top of my head). In general you should not expect the data field to live beyond the lifetime of the packet. When possible we try to optimize performance by having the data pointer point to a static location where the requester wants the final data to be placed, but it's also possible that it points to a dynamically allocated block that gets deleted when the packet is deleted. Steve On Thu, Jun 30, 2011 at 7:21 AM, Andreas Hansson <[email protected]>wrote: > Dear all, > > I am attempting to get a better understanding of the lifetime of packets, > and the requests and data they point to. This is crucial to understand: 1) > who is responsible for de-allocation (to avoid memory leaks), and 2) when it > is safe to de-allocate (to avoid SEGFAULTS etc). It also becomes > particularly interesting when multiple packets are involved in serving one > request, e.g. snoop packets, or forwarded packets in one or more bridges. > > The concrete example I am working with involves creating explicit snoop > messages in the bus (rather than sending the same message to all snoopers). > This is very similar to what is happening in the cache. The copied packets > point to the same request and data as the original packet, thus allowing > e.g. a cache to update the "original" location of the data, pointed to by > every single copy of the packet. However, these packets are deleted after > getting the state information from them (shared, inhibited etc), and at this > point the original request is also deallocated through the packets > destructor. > > How is this intended to work? Is there a rule to follow to avoid memory > leaks and segfaults, even in the presence of forwarding/multiple hops with > intermediate (life time during original) or succeeding packets (life time > beyond original)? > > I hope someone can shed some light on the matter. Thanks in advance. > > Best regards, > > Andreas > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
