> 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.? > > Ali Saidi wrote: > Not major changes, but things usually sped up a little bit. > > Ali Saidi wrote: > Actually it is quite a change for some benchmarks, it's just not uniform. > High of 17%, low of 0%, average of about 5%. So I think we need to fix it and > if it exposes other bugs, so be it, but the regression tests all complete > successfully. > > alpha > ------------------ > eon: 17% > twolf: 15% > vortex: 5% > gzip 0% > linux: 0% > bzip2: 3% > perlbmk: 2% > > > parc > -------------------- > gzip: 3% > > x86 > -------------------- > mcf: 17% > parser: 4% > twolf: 2% > gzip: 2% > > arm > ---------------------- > gzip: 7% > mcf: 2% > eon: 13% > twolf: 3% > parser: 3% > vortex: 6% > perlbmk: > bzip2: > linux: 1% > >
Yes, we shouldn't delay fixing this bug for the sake of the other ones that might be in there too. We should still add an assert if possible, though, so we catch those bugs if they happen. - Gabe ----------------------------------------------------------- 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 [email protected] http://m5sim.org/mailman/listinfo/m5-dev
