On Sun, Jul 4, 2010 at 4:54 PM, Ali Saidi sa...@umich.edu wrote:
Right, unless it is possible to take a checkpoint with a simple cpu
and then restore with the inorder cpu. In fact, that brings up my next
question. How does switching cpu work in conjunction with
checkpointing? Is it possible to
At some point in the past we were having trouble with that though, and
as a workaround we started doing the
restore-into-simple-cpu-for-one-cycle thing, and we've never gone back
to revisit it. If you think about it, life would be easier if you
didn't have to construct this ugly two-headed
Why are you trying to checkpoint the InOrderCPU? Wouldn't it be
better to implement the switchover from SimpleCPU to InOrder? You
can't checkpoint caches right now, so it doesn't seem worthwhile to
checkpoint inorder.
Nate
On Sat, Jul 3, 2010 at 1:56 PM, soumyaroop roy s...@cse.usf.edu
Why are you trying to checkpoint the InOrderCPU? Wouldn't it be
better to implement the switchover from SimpleCPU to InOrder? You
can't checkpoint caches right now, so it doesn't seem worthwhile to
checkpoint inorder.
If I'm not mistaken, soumyaroop had this almost working in the past and
Why are you trying to checkpoint the InOrderCPU? Wouldn't it be
better to implement the switchover from SimpleCPU to InOrder? You
can't checkpoint caches right now, so it doesn't seem worthwhile to
checkpoint inorder.
If I'm not mistaken, Soumyaroop had this almost working in the past and
On Sun, Jul 4, 2010 at 5:24 PM, Korey Sewell ksew...@umich.edu wrote:
Why are you trying to checkpoint the InOrderCPU? Wouldn't it be
better to implement the switchover from SimpleCPU to InOrder? You
can't checkpoint caches right now, so it doesn't seem worthwhile to
checkpoint inorder.
On Jul 4, 2010, at 6:44 PM, soumyaroop roy wrote:
On Sun, Jul 4, 2010 at 5:24 PM, Korey Sewell ksew...@umich.edu wrote:
Also,
Even without the caches being checkpointed (and subsequently warmed up),
wouldnt checkpointing still be useful to the degree that at least you have
the memory
Hello there:
I am revisiting an earlier suspended effort to implement checkpointing
for the inorder cpu and I am currently debugging a problem (for the
case of a uniprocessor and no multithreading). Let me describe the
problem here.
I am using the hello world program. I am taking a checkpoint at
On Sat, Jul 3, 2010 at 1:56 PM, soumyaroop roy s...@cse.usf.edu wrote:
Now, this is my understanding of how a checkpoint is taken. Please
correct me if I am wrong. I noted that when checkpointing is specified
with these options: --take-checkpoint=N --at-instruction, the
max_insts_any_thread
But fixing the two items above did not solve the problem. I figured
(from the takeoverfrom() routines) that commit stage needs to reset
its flags to that it does not go and squash the first instruction
where the restoration is supposed to start from. Since I am not very
familiar with the O3
I have made some progress on checkpointing.
Here are a few issues with checkpointing for o3 (based on which I was
implementing the same for inorder):
1. _status member was not being serialized which was preventing
scheduling of new events, thereby rendering the main event queue empty
(the simple
Yes, that is absolutely correct! the list of instructions to be
removed during a tick by the cleanUpRemovedInsts() routine comprises
of both instructions that graduate and instructions that get squashed!
And, cleanUpRemovedInsts() just removes the instruction schedule
associated (and its
Thanks for creating the wiki page. I will populate it after I am done
testing checkpoint restoration. Waiting for a resolution on the
restoration issue.
regards,
Soumyaroop
On 2/8/10, Korey Sewell ksew...@umich.edu wrote:
Yes, that is absolutely correct! the list of instructions to be
On Sun, Feb 7, 2010 at 8:36 AM, Korey Sewell ksew...@umich.edu wrote:
The checkSignalsAndUpdate() routine seems to be taking care of
squashes for each thread. FirstStage::processStage() proceeds to fetch
instructions after that. So, why not just insert the check on
drainPending between the
Let me rephrase my last question:
Is there any way that a comparison could be performed between the
checkpoint output by inorder with that output by a simple CPU? Say, if
the number of committed instructions in both are the same when the
checkpoints are dumped, should I expect that the register
On Sat, Feb 6, 2010 at 9:08 AM, soumyaroop roy s...@cse.usf.edu wrote:
Let me rephrase my last question:
Is there any way that a comparison could be performed between the
checkpoint output by inorder with that output by a simple CPU? Say, if
the number of committed instructions in both are the
On Sat, Feb 6, 2010 at 12:22 PM, Steve Reinhardt ste...@gmail.com wrote:
On Sat, Feb 6, 2010 at 9:08 AM, soumyaroop roy s...@cse.usf.edu wrote:
Let me rephrase my last question:
Is there any way that a comparison could be performed between the
checkpoint output by inorder with that output by a
Here is some more information about the error:
It looks like, while restoring from a checkpoint, it always starts off
with the simple-atomic cpu (check the setCPUClass() routine in
Simulation.py) and then switches to the other CPU (timing or O3 or
Inorder). Therefore, the
Thanks for the overview, Ali. It helped a lot. Draining is definitely
the trickier thing.
This is my understanding of the flow in O3:
1. When drain() is called, it sets the drainPending flag to TRUE
following which the fetch stage does not fetch any instructions.
2. Subsequently, when all the
1. The first stage of the pipeline should not process the stage when a
drainPending flag is set (or should this be associated specifically
with the fetch logic?)
This sounds good. There is already a checkSignals type function in the
pipeline stage definition that you may be able to play off
Hello there,
Could someone give me a quick overview on how to implement
checkpointing for inorder? I am not able to find any documentation for
it. So, I was trying to follow O3. But which methods - serialize(),
unserialize()? And what about cpu switching?
regards,
Soumyaroop
--
Soumyaroop Roy
You need to implement the following functions for the CPU. Taking a
look at the simple timing CPU should be an easier way to grasp what
must be done. Before the system can take a checkpoint, all the
requests must be drained from it. drain() is called on each simobject
which needs to
22 matches
Mail list logo
