----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1294/#review3312 -----------------------------------------------------------
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? - Anthony Gutierrez 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
