> On March 17, 2015, 12:07 p.m., Andreas Hansson wrote: > > src/mem/cache/cache_impl.hh, line 1417 > > <http://reviews.gem5.org/r/2691/diff/1/?file=44226#file44226line1417> > > > > the changed order of the write buffer allocation and dealing with the > > writebacks is important?
Good question. I reordered the two blocks only so I could put the tempBlock clause inside of 'if (!early_exit)' and leave the writebacks code outside. It's necessary to do the writebacks before exiting the function, since that's a local variable and otherwise the writebacks would be lost. In contrast, tempBlock is part of the cache object so it will stick around, and while I haven't thought it through carefully, I assume there could be cases where you're doing a locked RMW in tempBlock, so you don't want to kick it out prematurely. Looking at handleFill(), it seems unlikely (dare I say impossible) that you would have both writebacks and the use of tempBlock at the same time, since the only time you use tempBlock is if you can't use any existing cache block frame, and if you had bothered to do a writeback then by definition you would be clearing out an existing cache block frame. So by that reasoning the order shouldn't matter. - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2691/#review5943 ----------------------------------------------------------- On March 14, 2015, 10:19 a.m., Steve Reinhardt wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2691/ > ----------------------------------------------------------- > > (Updated March 14, 2015, 10:19 a.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 10745:9b84d1b570e3 > --------------------------- > mem: implement x86 locked accesses in timing-mode classic cache > > Add LockedRMW(Read|Write)(Req|Resp) commands. In timing mode, > use a combination of clearing permission bits and leaving > an MSHR in place to prevent accesses & snoops from touching > a locked block between the read and write parts of an locked > RMW sequence. > > > Diffs > ----- > > src/mem/cache/cache_impl.hh 655ff3f6352d7aa4021f8840b68698b277772806 > src/mem/packet.hh 655ff3f6352d7aa4021f8840b68698b277772806 > src/mem/packet.cc 655ff3f6352d7aa4021f8840b68698b277772806 > > Diff: http://reviews.gem5.org/r/2691/diff/ > > > Testing > ------- > > > Thanks, > > Steve Reinhardt > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
