> On April 1, 2015, 4:28 p.m., Steve Reinhardt wrote: > > src/mem/cache/cache_impl.hh, line 1724 > > <http://reviews.gem5.org/r/2717/diff/1/?file=44386#file44386line1724> > > > > is this really necessary? I'm curious why setting this flag actually > > breaks things
We are not clearing it for the cache we are snooping into (see the block above), so it feels rather dodgy to pass the flag along here even if the recipient ignores it. Agreed? > On April 1, 2015, 4:28 p.m., Steve Reinhardt wrote: > > src/mem/cache/cache_impl.hh, line 1768 > > <http://reviews.gem5.org/r/2717/diff/1/?file=44386#file44386line1768> > > > > create a helper function for this loop, since it also appears below > > now? or maybe we should convert AddrRangeList to a class, and add this as > > a method... Sure, I'll make a little helper function > On April 1, 2015, 4:28 p.m., Steve Reinhardt wrote: > > src/mem/cache/mshr.cc, line 375 > > <http://reviews.gem5.org/r/2717/diff/1/?file=44387#file44387line375> > > > > same comment as above Same reason as above. It feels odd to set the flag that is later ignored. - Andreas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2717/#review6005 ----------------------------------------------------------- On March 30, 2015, 9:17 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2717/ > ----------------------------------------------------------- > > (Updated March 30, 2015, 9:17 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10783:84330bcae3c6 > --------------------------- > mem: Snoop into caches on uncacheable accesses > > This patch takes a last step in fixing issues related to uncacheable > accesses. We do not separate uncacheable memory from uncacheable > devices, and in cases where it is really memory, there are valid > scenarios where we need to snoop since we do not support cache > maintenance instructions (yet). On snooping an uncacheable access we > thus provide data if possible. In essence this makes uncacheable > accesses IO coherent. > > The snoop filter is also queried to steer the snoops, but not updated > since the uncacheable accesses do not allocate a block. > > At the moment there are quite a few special cases where we > need to check to ensure uncacheable accesses do not steal exclusivity > etc, and perhaps there is a nicer way to embed these checks in the > existing packet methods. > > > Diffs > ----- > > src/mem/cache/mshr.cc 8a7285d6197e > src/mem/coherent_xbar.cc 8a7285d6197e > src/mem/snoop_filter.cc 8a7285d6197e > src/cpu/o3/cpu.cc 8a7285d6197e > src/dev/dma_device.cc 8a7285d6197e > src/mem/cache/cache_impl.hh 8a7285d6197e > > Diff: http://reviews.gem5.org/r/2717/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
