> On Aug. 24, 2012, 1:36 p.m., Anthony Gutierrez wrote: > > This code also helped me get past some assertion failures. I am not quite > > sure how the tmp block stuff works and with this patch it seems like we > > shouldn't really be calling invalidateBlk() on tmp blks at all. Is the > > reason why this works because tmp blocks don't really belong to any set?
Yes. Lena was going to clean up how this was done. We haven't committed this patch because we've been waiting for the cleanup, but perhaps we should just commit this for the time being. - Ali ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1294/#review3312 ----------------------------------------------------------- On July 5, 2012, 6:08 p.m., Lena Olson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1294/ > ----------------------------------------------------------- > > (Updated July 5, 2012, 6:08 p.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9072:f58254385d89 > --------------------------- > Cache: Handle invalidation of temporary blocks correctly > > The cache sometimes calls invalidateBlk on the temporary block, which has > just been used to hold data that could not be given a place in the cache. To > differentiate this case, the block is marked as not valid before > invalidateBlk is called. In that case, it should be handled differently -- > the LRU pointers should not be updated. > > > Diffs > ----- > > src/mem/cache/tags/lru.cc fa77985a87c6ff77284ed9bdd4ae304b2e373666 > > Diff: http://reviews.gem5.org/r/1294/diff/ > > > Testing > ------- > > > Thanks, > > Lena Olson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
