> On Nov. 23, 2012, 1 p.m., Ali Saidi wrote: > > Looks good to me. Is the default parameter for request necessary? > > > >
Think my post got eaten. It's currently necessary because the invalidate() call in blk.hh also calls clearLoadLocks(). I could have just made two functions. One that clears all locks to a line (called by invalidate), and one that clears a specific address range given an address. I just coded it this way so that I'd have fewer source code changes. - Mitch ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1540/#review3708 ----------------------------------------------------------- On Nov. 20, 2012, 3:46 p.m., Mitch Hayenga wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1540/ > ----------------------------------------------------------- > > (Updated Nov. 20, 2012, 3:46 p.m.) > > > Review request for Default. > > > Description > ------- > > The current implementation in gem5 just keeps a list of locks per cacheline. > Due to this, a store to a non-overlapping portion of the cacheline can cause > an LL/SC pair to fail. This patch simply adds an address range to the lock > structure, so that the lock is only invalidated if the store overlaps the > lock range. > > > Diffs > ----- > > src/mem/cache/blk.hh 94383c5124d2 > > Diff: http://reviews.gem5.org/r/1540/diff/ > > > Testing > ------- > > Have been using it myself for a few weeks on mostly SE, single-threaded code. > Have also run the quick regressions, the o3-timing regressions "fail" simply > because the stats differ (fewer LL/SC pairs executed, because they are now > succeeding on their first try). > > > Thanks, > > Mitch Hayenga > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
