----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3251/#review7779 -----------------------------------------------------------
Hey, I posted some comments but never gave this a ship it... I was going to say that neither solution (previous or current) seems all that great to me. Seems like if we really just want to know whether this request was issued by this cache or not, we ought to be able to do something straightforward like check req->masterId(), no? Not that I'm a total purist or anything (and apparently I missed you doing the same trick elsewhere), but I'm not totally comfortable with using RequestPtr as a transaction ID or an STL set to model anything other than a fully associative hardware table. FYI, the idea with SenderState is that it's really a shortcut for a master's outstanding transaction table, where normally you'd allocate a table entry and put a table index in the transaction as a tag, then do a table lookup based on that tag as a response. I thought this was discussed in the SenderState comment, but I see that it's not, unfortunately. The dynamic_cast is an abuse of this model as well, which is why I'm not defending the status quo here, just hoping that we can find a more straightforward replacement for it. - Steve Reinhardt On Dec. 24, 2015, 12:22 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3251/ > ----------------------------------------------------------- > > (Updated Dec. 24, 2015, 12:22 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11277:b0171dac1864 > --------------------------- > mem: Do not use sender state to track forwarded snoops in cache > > This patch changes how the cache tracks which snoops are forwarded, > and which ones are created locally. Previously the identification was > based on an empty sender state of a specific class, but this method > fails to distinguish which cache actually attached the sender > state. Instead we use the same mechanism as the crossbar, and keep > track of the requests that have outstanding snoops. > > > Diffs > ----- > > src/mem/cache/cache.hh d9a0136ab8cc > src/mem/cache/cache.cc d9a0136ab8cc > > Diff: http://reviews.gem5.org/r/3251/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
