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
