On June 24, 2015, 7: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.
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. - Timothy ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2908/#review6581 ----------------------------------------------------------- On June 24, 2015, 7: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, 7: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
