Ah, I understand the issue now. Yes, your solution manipulating the event queue seems like it will work.
It would be nice if we could have a regression test that can test this functionality once you check it in. I could imagine a further checkin accidently breaking this process. Brad > -----Original Message----- > From: Nilay Vaish [mailto:[email protected]] > Sent: Friday, December 09, 2011 8:02 AM > To: Beckmann, Brad > Cc: Steve Reinhardt; Ali Saidi; Gabe Black; Nathan Binkert; Default > Subject: RE: Review Request: Ruby: Resurrect Cache Warmup Capability > > I thought more about this. It seems we can do it in the same manner as we > do things in unserialize(). In the serialize() function, we can change the > event > queue head, issue the cache flush requests, and then call simulate(). Once > the caches are flushed, the event queue head is restored and the memory > image is checkpointed. > > -- > Nilay > > On Thu, 8 Dec 2011, Nilay Vaish wrote: > > > I was initially thinking that a flush request for line is issued along > > with it being added to the trace. But then, I realized (I might be > > wrong here), that once the system has got drained, it may no longer > process any events. > > This means that the flush requests would actually not be processed at all. > > > > -- > > Nilay > > > > On Thu, 8 Dec 2011, Beckmann, Brad wrote: > > > >> I was imagining that we flush the caches during the > >> serialization/checkpointing process, not before it. I'm thinking the > >> cache trace creation is the first step of the Ruby serialize > >> function, then we flush the caches, and final we take the memory > >> checkpoint. Is there a reason we can do that in that order? > >> > >> Brad > >> > >> > >>> -----Original Message----- > >>> From: Nilay Vaish [mailto:[email protected]] > >>> Sent: Thursday, December 08, 2011 3:58 PM > >>> To: Beckmann, Brad > >>> Cc: Steve Reinhardt; Ali Saidi; Gabe Black; Nathan Binkert; Default > >>> Subject: RE: Review Request: Ruby: Resurrect Cache Warmup Capability > >>> > >>> Brad, you are right. Now that I think of it, it really does not make > >>> much sense to take periodic checkpoints when the simulation is in > >>> timing mode (and not in atomic mode) as checkpointing interferes > >>> with the timing. > >>> > >>> I was thinking about checkpointing the memory image. I have not been > >>> able to convince myself about some reasonably correct way of doing > >>> this. We need to flush the caches, before we can take a checkpoint. > >>> It appears this can only happen while the system is draining. My > >>> understanding of cache flushing is that it would write back the data > >>> to the memory and invalidate the cache line. Since the cache does > >>> not have the line any more, this means that we cannot have that line > >>> in the cache trace. It seems only the lines that have access > >>> permission as Read_Only can be part of the cache trace. Is my > >>> understanding correct? > >>> > >>> Thanks > >>> Nilay > >>> > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
