Hi Tim, I think we should keep the cache tracing functionality. I've used cache warm-up after taking repeated checkpoints to find particular system activity levels, and I only restore+simulate those that meet some criteria (i.e. like simpoints). Often, the intervals simulated between these checkpoints are fine-grained, so it is important to be able to do cache cool-down and warm-up in a slim, automatic way. I expect we would rather not try to figure out another means of warming up caches.
Can you describe the restore problems you're running into? Perhaps we can help debug. Joel On Thu, Jun 18, 2015 at 2:31 AM, Timothy M Jones <[email protected] > wrote: > Hi Brad, > > On 17/06/2015 21:38, Beckmann, Brad wrote: > >> The benefit for creating at trace, rather than just inserting data into >> the cache, is two-fold. First, by creating a trace from a very large cache >> system, one can warmup caches of different sizes, associativities and even >> completely different cache hierarchies/configurations from a single trace. >> Second, and probably more important, Ruby protocols rely on timing requests >> to set cache block state to the unique states used by a particular >> protocol. Often Ruby is used to compare different protocols and this >> process allows us to compare protocols using the exact same checkpoint. >> >> Thanks for the explanation. OK, so I understand why you want to have a > trace, but is there any need for it, or could you just start at a > checkpoint with a totally empty cache (as in the classic model)? Basically, > is this trace simply a way to avoid the need to warm up the caches after a > checkpoint? > > At the moment I can create the trace at a checkpoint, which is progress, > but I get problems both in the simulator and simulated system when > restoring from the checkpoint. I'd like to know whether to invest the time > in getting this to work, or whether I should simply implement > memWriteback() for ruby to flush dirty data before a checkpoint, then do > away with the trace altogether. > > Cheers > Tim > > -- > Timothy M. Jones > http://www.cl.cam.ac.uk/~tmj32/ > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > -- Joel Hestness PhD Candidate, Computer Architecture Dept. of Computer Science, University of Wisconsin - Madison http://pages.cs.wisc.edu/~hestness/ _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
