> On Oct. 19, 2015, 1:27 a.m., Steve Reinhardt wrote: > > The original idea was to provide the MSHR a general hook to influence > > protocol actions; since this one action of promoting targets on an > > unexpected exclusive block is the only thing that materialized, it's fine > > with me to un-generalize it for clarity. However, if we're going to do > > that, then we don't need to pass the packet in either, as long as we do the > > exclusive check outside the call, as shown below.
Sure, I'm fine either way. If you prefer to see it changed I'm happy to go ahead and change it. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3151/#review7393 ----------------------------------------------------------- On Oct. 13, 2015, 4:49 p.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3151/ > ----------------------------------------------------------- > > (Updated Oct. 13, 2015, 4:49 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11170:8e7da5c45d78 > --------------------------- > mem: Clarify cache MSHR handling on fill > > This patch addresses the upgrading of deferred targets in the MSHR, > and makes it clearer by explicitly calling out what is happening > (deferred targets are promoted if we get exclusivity without asking > for it). > > > Diffs > ----- > > src/mem/cache/cache.cc 44b5c183c3cd > src/mem/cache/mshr.hh 44b5c183c3cd > src/mem/cache/mshr.cc 44b5c183c3cd > > Diff: http://reviews.gem5.org/r/3151/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
