> On Oct. 19, 2015, 1:49 a.m., Steve Reinhardt wrote: > > Can you elaborate on the ordering issue? Couldn't it be solved just by > > making sure the appropriate latencies are used? > > > > Also, I know it's outside the scope of this patch, but 'force_order' is a > > really ambiguous name, and I originally thought it had the opposite effect > > that it does. Basically packets in the queue can be timestamp ordered or > > insertion-sequence ordered, and 'order' doesn't disambiguate between those.
I don't mind people using latencies to "ensure" this re-ordering never happens, but I find that incredibly brittle. As stated in the patch description, the issue arises when a snoop response is forwarded through a cache, and scheduled to be sent, but before the response is sent, a new request comes in, and the request-response latency is lower than the time when the snoop response is going out. The stricted checks in the snoop filter catch the violation. I am happy to change the name, but I'd really like the functionality to be all there first. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3152/#review7394 ----------------------------------------------------------- On Oct. 13, 2015, 3:36 p.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3152/ > ----------------------------------------------------------- > > (Updated Oct. 13, 2015, 3:36 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11171:4bbaf47ddcc8 > --------------------------- > mem: Enforce packet order on the cache response path > > This patch enforces insertion order transmission of packets on the > response path in the cache. Note that the logic to enforce order is > already present in the packet queue, this patch simply turns it on for > queues in the response path. > > Without this patch, there are corner cases where a request-response is > faster than a response-response forwarded through the cache. This > violation of queuing order causes problems in the snoop filter leaving > it with inaccurate information. This causes assert failures in the > snoop filter later on. > > A follow on patch relaxes the order enforcement in the packet queue to > limit the performance impact. > > > Diffs > ----- > > src/mem/cache/cache.cc 44b5c183c3cd > src/mem/qport.hh 44b5c183c3cd > > Diff: http://reviews.gem5.org/r/3152/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
