> On July 2, 2015, 3:23 p.m., Jason Power wrote: > > What did you use to test this? It would be wonderful if we had a regression > > script for Ruby and checkpointing! No need to hold up this bugfix patch for > > it, but if you could cobble a test together quickly it would be nice to > > have. If not, let me know how you are testing this patch and I might put > > something together. > > Timothy Jones wrote: > Hi Jason, > > Unfortunately it was a bit long-winded to test. I had to boot Linux with > 2 cores and start running x264 from Parsec, taking the checkpoint at the ROI. > I couldn't seem to get the second error to happen earlier (e.g. at the start > of OS booting) but I didn't try extensively. Theoretically, it should have > manifested itself as soon as there was dirty data in the cache and a > checkpoint was taken. I'm happy to share my kernel and disk image, if > necessary, but perhaps this is overkill? > > Cheers > Tim
OK. It's unfortunate that things like this are so hard to track down. Maybe a solution is to test checkpointing while running the Ruby tester? I'll put it on the list of "things it would be nice to do if I never slept" ;). - Jason ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2908/#review6684 ----------------------------------------------------------- On July 1, 2015, 7:45 p.m., Timothy Jones wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2908/ > ----------------------------------------------------------- > > (Updated July 1, 2015, 7:45 p.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 when the event queue is altered by ruby during > serialization, > some events that are currently scheduled cannot be found (e.g. the event to > stop simulation that always lives on the queue), causing a panic. The second > is that ruby is sometimes serialized after the memory system, meaning that the > dirty data in its cache is flushed back to memory too late and so isn't > included in the checkpoint. > > These are fixed by implementing memory writeback in ruby, using the same > technique of hijacking the event queue, but first descheduling all events that > are currently on it. They are saved, along with their scheduled time, so that > the event queue can be faithfully reconstructed after writeback has finished. > Writeback is still implemented using flushing, so the cache recorder object, > that is created to generate the trace and manage flushing, is kept around and > used during serialization to write the trace to disk. > > > Diffs > ----- > > src/mem/ruby/system/CacheRecorder.cc e4f63f1d502d > src/mem/ruby/system/System.hh e4f63f1d502d > src/mem/ruby/system/System.cc e4f63f1d502d > src/sim/eventq.hh 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
