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
