That could be an issue, but I would imagine that the stats aren't that important to the user if they're taking a checkpoint at the end of their run. I agree that it would be nice to avoid the flush from perturbing the results, but I don't think it is a "show stopper".
Brad From: Steve Reinhardt [mailto:[email protected]] Sent: Friday, December 09, 2011 10:51 AM To: Beckmann, Brad Cc: Nilay Vaish; Ali Saidi; Gabe Black; Nathan Binkert; Default Subject: Re: Review Request: Ruby: Resurrect Cache Warmup Capability Have you looked at issues with statistics or other Ruby state that might make this process awkward? E.g., will the flush operations affect the stats, or are there timestamps in some of the controllers that will get confused if time does not increase monotonically? Steve On Fri, Dec 9, 2011 at 9:07 AM, Beckmann, Brad <[email protected]<mailto:[email protected]>> wrote: 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]<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]<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
