I'm curious to know why you want to support periodic checkpointing with Ruby. Certainly periodic checkpointing with the Classic memory system is desired, especially in atomic mode. It makes sense to use Classic+atomic w/ periodic checkpointing to find the interesting parts of a workload and the run from those interesting checkpoints using more detailed simulation (Ruby, O3, etc.). However, due to the slowdown of Ruby, it is not clear to me why one would want to use periodic checkpointing with Ruby. Furthermore, as you know, taking a Ruby checkpoint perturbs the system. Ruby requires that all outstanding requests be completed before checkpointing the memory and cache state. I would like to avoid having to take a Ruby checkpoint unless absolutely necessary. One may argue that we should checkpoint all the outstanding state in Ruby so that checkpoint doesn't perturb the system, but I strongly believe that it is important to make Ruby checkpoints protocol and configuration agnostic. Tuning workloads is a tough job and once one creates a good set of checkpoints, you want to leverage that work as much as possible.
Brad > -----Original Message----- > From: Nilay Vaish [mailto:[email protected]] > Sent: Thursday, December 08, 2011 6:56 AM > To: Beckmann, Brad > Cc: Steve Reinhardt; Ali Saidi; Gabe Black; Nathan Binkert; Default > Subject: RE: Review Request: Ruby: Resurrect Cache Warmup Capability > > Brad, but flushing the caches would mean that we cannot support periodic > checkpointing. > > -- > Nilay > > On Wed, 7 Dec 2011, Beckmann, Brad wrote: > > > Switching to email. > > > > The thing to remember is the cache trace doesn’t keep track of whether > > shared data is dirty or not. It simply marks that address for a load > > request. We don’t want to store dirty state in the cache since we > > want to make these traces protocol agnostic and each protocol can > > potentially manage dirty data differently. That is why the current > > patch breaks those checks. > > > > Brad > > > > > > > > Brad, thanks for the review. I can take care of all of the things you > > have pointed > > > > out. I'll add functions for serializing and unserializing the memory image. > > > > > > > > But I have other questions. Is flushing the cache necessary? If we are > > correctly > > > > restoring the data in the caches, I think that we can checkpoint the > > memory > > > > image even with stale data. Secondly, why were those checks breaking > earlier? > > > > I picked those lines directly from the patch you had provided to Somayeh. > > > > > > - Nilay > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
