summaryrefslogtreecommitdiff
path: root/configs/ruby
diff options
context:
space:
mode:
authorTimothy Jones <timothy.jones@cl.cam.ac.uk>2015-08-03 23:08:40 -0500
committerTimothy Jones <timothy.jones@cl.cam.ac.uk>2015-08-03 23:08:40 -0500
commit96091f358b97a10e261422aebefd6b5c187c2a60 (patch)
tree980363b7a135bec640e8128b3adc2202b65207a9 /configs/ruby
parent676ae5782796bd6b4f202e138b72c1048efceabd (diff)
downloadgem5-96091f358b97a10e261422aebefd6b5c187c2a60.tar.xz
uby: 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. Events with the AutoDelete flag set will delete themselves when they are descheduled, causing an error when attempting to schedule them again. This is fixed by simply not recording them when taking them off the queue. 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. Committed by: Nilay Vaish <nilay@cs.wisc.edu>
Diffstat (limited to 'configs/ruby')
0 files changed, 0 insertions, 0 deletions