> On Feb. 3, 2016, 10:34 p.m., Steve Reinhardt wrote: > > I would like to review this more closely, but am having trouble finding the > > time, so perhaps there's no need to wait on me. I do have a couple of > > higher-level questions though: > > 1. What are the topology constraints for this? Does it assume that there's > > one global crossbar that has this flag set, and any other crossbars do not? > > Or could you have multiple crossbars serving disjoint parts of the address > > space? > > 2. Qualitatively, does this create another set of hierarchy variants that > > increase the amount of testing required for coherence protocol changes, or > > is it sufficiently orthogonal to the protocol itself that you don't think > > this is a big deal?
1. No topology constraints really. Each unique line address has one point of coherency, but you can stripe or split address ranges across multiple crossbars if you want. 2. Not really. It just moves the point of coherency from the memory controller to the crossbar. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3271/#review7986 ----------------------------------------------------------- On Jan. 1, 2016, 2:33 p.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3271/ > ----------------------------------------------------------- > > (Updated Jan. 1, 2016, 2:33 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11297:bcef70bdf6e3 > --------------------------- > mem: Move the point of coherency to the coherent crossbar > > This patch introduces the ability of making the coherent crossbar the > point of coherency. If so, the crossbar does not forward packets where > a cache with ownership has already committed to responding, and also > does not forward any coherency-related packets that are not intended > for a downstream memory controller. Thus, invalidations and upgrades > are turned around in the crossbar, and the memory controller only sees > normal reads and writes. > > In addition this patch moves the express snoop promotion of a packet > to the crossbar, thus allowing the downstream cache to check the > express snoop flag (as it should) for bypassing any blocking, rather > than relying on whether a cache is responding or not. > > > Diffs > ----- > > src/mem/XBar.py 57c340f947c7 > src/mem/bridge.cc 57c340f947c7 > src/mem/cache/cache.cc 57c340f947c7 > src/mem/coherent_xbar.hh 57c340f947c7 > src/mem/coherent_xbar.cc 57c340f947c7 > src/mem/dram_ctrl.cc 57c340f947c7 > src/mem/simple_mem.cc 57c340f947c7 > configs/example/memtest.py 57c340f947c7 > > Diff: http://reviews.gem5.org/r/3271/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
