You could certainly do that. You are absolutely correct that a Ruby simulation does not need a trace to run from a checkpoint.
Brad -----Original Message----- From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Timothy M Jones Sent: Thursday, June 18, 2015 12:32 AM To: gem5-dev@gem5.org Subject: Re: [gem5-dev] Ruby serialize removing event queue head 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 gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
