> On 2011-02-27 21:41:48, Gabe Black wrote: > > Should we put an assert in there to make sure no access is bigger than 16 > > bytes? Also what about unaligned accesses? I think those will be split on > > cache block boundaries which may be bigger or smaller than 16 bytes. We > > might have an access that spans from one 16 byte chunk to the next. These > > aren't really problems with this change, but it might make them easier to > > hit. > > > > I'm assuming this had some effect on the regressions. Did things generally > > go faster, slower, etc.?
Not major changes, but things usually sped up a little bit. - Ali ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/520/#review915 ----------------------------------------------------------- On 2011-02-27 18:52:51, Ali Saidi wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.m5sim.org/r/520/ > ----------------------------------------------------------- > > (Updated 2011-02-27 18:52:51) > > > Review request for Default, Ali Saidi, Gabe Black, Steve Reinhardt, and > Nathan Binkert. > > > Summary > ------- > > O3: Tighten memory order violation checking to 16 bytes. > > The comment in the code suggests that the checking granularity should be 16 > bytes, however in reality the shift by 8 is 256 bytes which seems much > larger than required. > > > Diffs > ----- > > src/cpu/o3/lsq_unit_impl.hh 9dc17725f795 > > Diff: http://reviews.m5sim.org/r/520/diff > > > Testing > ------- > > > Thanks, > > Ali > > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
