----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2784/#review6874 -----------------------------------------------------------
This is dangerous. The whole idea is that we do not send things in 0 time (infinite throughput). Admittedly the +1 is a poor-mans version of a delta-delay, but I fear this interacts with a lot of things. What is the impact on (classic) cache performance, the other CPUs etc? - Andreas Hansson On July 31, 2015, 3:17 p.m., Tony Gutierrez wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2784/ > ----------------------------------------------------------- > > (Updated July 31, 2015, 3:17 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10841:b015addd7b9d > --------------------------- > mem: Ruby response timing > > This patch ensures that Ruby responses to the CPU core are not unnecessarily > delayed. The original code delays Ruby responses by a tick, causing the core > to receive them a cycle later, rather than in the same cycle. Hence, the > throughput of back-to-back stores that hit in the L1 are reduced by > half because the O3 must wait for the acknowledgement of a prior store before > issuing the next store. This patch eliminates the performance bug. > > This patch was created by Bihn Pham during his internship at AMD. > > > Diffs > ----- > > src/mem/packet_queue.cc fbdaa08aaa426b9f4660c366f934ccb670d954ec > > Diff: http://reviews.gem5.org/r/2784/diff/ > > > Testing > ------- > > > Thanks, > > Tony Gutierrez > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
