Searched hist:9063 (Results 1 - 3 of 3) sorted by relevance
| /gem5/src/mem/ | ||
| H A D | tport.hh | 9063:965c042379df Thu Jun 07 10:59:00 EDT 2012 Ali Saidi <Ali.Saidi@ARM.com> mem: Delay deleting of incoming packets by one call. This patch is a temporary fix until Andreas' four-phase patches get reviewed and committed. Removing FastAlloc seems to have exposed an issue which previously was reasonable rare in which packets are freed before the sending cache is done with them. This change puts incoming packets no a pendingDelete queue which are deleted at the start of the next call and thus breaks the dependency between when the caller returns true and when the packet is actually used by the sending cache. Running valgrind on a multi-core linux boot and the memtester results in no valgrind warnings. |
| H A D | tport.cc | 9063:965c042379df Thu Jun 07 10:59:00 EDT 2012 Ali Saidi <Ali.Saidi@ARM.com> mem: Delay deleting of incoming packets by one call. This patch is a temporary fix until Andreas' four-phase patches get reviewed and committed. Removing FastAlloc seems to have exposed an issue which previously was reasonable rare in which packets are freed before the sending cache is done with them. This change puts incoming packets no a pendingDelete queue which are deleted at the start of the next call and thus breaks the dependency between when the caller returns true and when the packet is actually used by the sending cache. Running valgrind on a multi-core linux boot and the memtester results in no valgrind warnings. |
| /gem5/src/mem/cache/ | ||
| H A D | cache.hh | 9063:965c042379df Thu Jun 07 10:59:00 EDT 2012 Ali Saidi <Ali.Saidi@ARM.com> mem: Delay deleting of incoming packets by one call. This patch is a temporary fix until Andreas' four-phase patches get reviewed and committed. Removing FastAlloc seems to have exposed an issue which previously was reasonable rare in which packets are freed before the sending cache is done with them. This change puts incoming packets no a pendingDelete queue which are deleted at the start of the next call and thus breaks the dependency between when the caller returns true and when the packet is actually used by the sending cache. Running valgrind on a multi-core linux boot and the memtester results in no valgrind warnings. |
Completed in 48 milliseconds