Reading the code, it seems to me that one can never checkpoint the state
of an atomic CPU while an atomic operation is going on. Here is some code
for help --
AtomicCPU::tick()
{
for (int i = 0; i < width || locked; ++i) {
// break if cpu in idle state
// do something
}
}
From the code, it seems if an atomic operation started, it has to end
before this loop can be exited. Even if a checkpoint instruction appears
between a pair of locked load and store, the checkpoint event will happen
only after the current event i.e. this processor's tick() function gets
completed.
I think we can take out this 'locked' variable out of the checkpoint. As a
check we can panic() in case locked variable is set to true and
serialize() gets called.
--
Nilay
On Wed, 4 Apr 2012, Gabe Black wrote:
Yes, that makes sense. I haven't checked into those other checkpointed
values you mentioned, but you should see what they're for and whether
they introduce their own complications.
Gabe
On 04/04/12 12:24, Ali Saidi wrote:
You could probably implement the drain() function in the atomic cpu
to do this.
Ali
On 04.04.2012 15:00, Nilay Vaish wrote:
So, is
it possible to delay the checkpointing process till all the CPUs
are
done with their current locked memory operations? Or do you think it
is possible that such a time may never arrive, in which case switching
to
timing mode is not possible?
--
Nilay
On Tue, 3 Apr
2012, Gabe Black wrote:
I haven't looked at the code in depth, but
I think "locked" describes whether or not you're in the middle of a
locked (roughly atomic) operation. Not keeping track of that would be
bad, although transferring that to timing mode would be tricky. On the
other hand, timing mode doesn't implement locked memory operations
anyway, so... Gabe On 04/03/12 21:53, Nilay Vaish wrote:
What I
wrote was more of a hypothesis that might explain / help debug the
problem Joel is facing. I might be incorrect, though I faintly recall
facing some such problem my self. I am more in favor of moving towards
storing only architectural state in the checkpoint so that we can
restore from any cpu type. Any ideas as to why we need fields like
so_state, locked, status for atomic CPU? -- Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
