On June 24, 2015, 8:49 a.m., Timothy Jones wrote:
> > I do not think this is the way to go. There is already an established
> > methodology to solve the issue.
>
> Timothy Jones wrote:
> I don't think draining is the way forward, but there could well be other,
> better solutions than the one I've got here. My aim was to get this working
> again, which is does, but I'm happy now to rework it into something more
> acceptable.
>
> From my understanding, draining is there to remove transient state from
> objects. In the classic memory model caches keep dirty data around after
> draining, so I don't see why ruby shouldn't either.
>
> However, in the classic model, a call to memWriteback() is made to flush
> data back to memory before checkpointing. Perhaps it would be better if I
> implemented ruby's flushing in a similar function? The main problem with
> that is that ruby's flushing is tied up with creating a trace for
> checkpointing, so if someone wanted to call memWriteback() without creating
> then creating a checkpoint, then they'd end up with an unnecessary trace file.
I agree with Andreas here. Having checkpoint priorities seems like a really bad
idea.
You're right that the expectation is that drain does not flush or write back
caches. The simulator is drained when switching CPU models (there are cases
where we write back and invalidate caches here, but I don't think those are
supported by Ruby) and you really don't want to lose your cache in that case.
The flow when taking a checkpoint is slightly different since we assume that
caches in the classic memory system can't be checkpointed. This means that the
simulator goes through the following flow:
* drain() (called multiple times until the whole simulator is drained)
* memWriteback()
* serialize()
* drainResume()
I *think* the right solution here would be to write back dirty data to the
memory system in memWriteback() and create the trace in serialize(). This would
ensure that the backing store is in sync with Ruby when you take the
checkpoint. Note that you aren't required to change the state of dirty cache
lines in memWriteback(), this would allow you to retain the old state in the
trace.
- Andreas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2908/#review6581
-----------------------------------------------------------
On June 24, 2015, 8:43 a.m., Timothy Jones wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2908/
> -----------------------------------------------------------
>
> (Updated June 24, 2015, 8:43 a.m.)
>
>
> Review request for Default and Ruby Reviewers.
>
>
> Repository: gem5
>
>
> Description
> -------
>
> ruby: Fix checkpointing and restore
>
> There are 2 problems with the existing checkpoint and restore code in ruby.
> The first is that the event queue is altered by ruby during serialization,
> meaning that the event to stop simulation that always lives on the queue
> can't be found, causing a panic. This is fixed by explicitly descheduling it
> before swapping events off the main queue.
>
> The other happens occasionally when ruby is serialized after the memory
> system. In this case the dirty data in ruby's caches is flushed back to
> memory too late and so isn't included in the checkpoint. This is fixed by
> adding serialization priorities, thus ensuring that ruby can be serialized
> first, perform its flush, and make sure memory has the most up-to-date data
> before it is checkpointed too.
>
>
> Diffs
> -----
>
> src/mem/ruby/system/CacheRecorder.cc e4f63f1d502d
> src/mem/ruby/system/System.cc e4f63f1d502d
> src/sim/sim_object.hh e4f63f1d502d
> src/sim/sim_object.cc e4f63f1d502d
>
> Diff: http://reviews.gem5.org/r/2908/diff/
>
>
> Testing
> -------
>
>
> Thanks,
>
> Timothy Jones
>
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
