----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2703/#review5963 -----------------------------------------------------------
Can you elaborate a bit on the functional issue for timing mode? I can see where this makes a difference for atomic, but in timing mode arbitration between misses and writebacks is done in getNextMSHR() and isn't based on the order into which things are placed in mshrQueue vs. writeBuffer (except in the case where there are conflicts, which I don't think can happen here, since you wouldn't be writing back block X if you're making room for a request to block X). Is this strictly related to uncacheable accesses? Or is it really just an atomic-mode fix and you're changing the timing code to be consistent? src/mem/cache/cache_impl.hh <http://reviews.gem5.org/r/2703/#comment5204> how about just creating a block here (from before this decl to after the loop) to localize the scope of 'writebacks', so we don't have to bother with the assert at the bottom? src/mem/cache/cache_impl.hh <http://reviews.gem5.org/r/2703/#comment5205> comment is wrong, we're issuing the writebacks (no write buffer in atomic mode) src/mem/cache/cache_impl.hh <http://reviews.gem5.org/r/2703/#comment5206> looks like these were the only uses of writebackVisitor() and invalidateVisitor()... should we get rid of them? TBH I missed when they were introduced. - Steve Reinhardt On March 22, 2015, 12:35 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2703/ > ----------------------------------------------------------- > > (Updated March 22, 2015, 12:35 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10765:3628e18edb65 > --------------------------- > mem: Allocate cache writebacks before new MSHRs > > This patch changes the order of writeback allocation such that any > writebacks resulting from a tag lookup (e.g. for an uncacheable > access), are added to the writebuffer before any new MSHR entries are > allocated. This ensures that the writebacks logically precedes the new > allocations. > > The patch also changes the uncacheable flush to use proper timed (or > atomic) writebacks, as opposed to functional writes. > > > Diffs > ----- > > src/mem/cache/cache.hh 48a72150f82c > src/mem/cache/cache_impl.hh 48a72150f82c > > Diff: http://reviews.gem5.org/r/2703/diff/ > > > Testing > ------- > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
