> On July 19, 2012, 10:25 a.m., Steve Reinhardt wrote: > > I agree with your removal of the serialization code, but I think there are > > important caveats. On one hand, it makes sense that I should be able to > > take a checkpoint with a 1GHz CPU and restore that to a 2GHz CPU (just like > > I can transition from a simple CPU to O3 via a checkpoint). On the other > > hand, we will need to be very careful that state derived from the clock > > (e.g., the next event time, or some latency values) is also recalculated > > and not serialized. I don't know that there's anything to do about it at > > this point; this is just yet another category of potential bugs to keep an > > eye out for. > > Nathan Binkert wrote: > Along those lines, what about dynamic frequency scaling and such? It's a > rare use case, but certainly will become more common. Seems like we need an > option to checkpoint values, but be able to override them in the > configuration. Then again, perhaps nobody will be doing DVFS before the > checkpoint is dropped. > > Steve Reinhardt wrote: > Actually I think DVFS will make checkpointing clock values less > necessary... basically as the rest of the code gets used to the idea of > having the clock change out from under it, then it will naturally also deal > with having the clock change because you unserialized from a checkpoint that > was taken with different clock values. > > The only thing to remember is that if we end up having a method that > needs to be called when the clock changes to keep other state in sync, then > we should also call those after an unserialization. (Or if we want to be > really conservative, we could serialize the clock values in ClockedObject, > and only call the method if the configure value is different from the > serialized value.) But this is all future work...
Well, the kernel needs to know (since it controls the frequency and thinks it knows what's going on.) Being in the situation where the kernel thinks you're at one frequency, but in reality, you're running at another can cause problems if you're not careful. - Nathan ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1303/#review3099 ----------------------------------------------------------- On July 19, 2012, 5:46 a.m., Andreas Hansson wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1303/ > ----------------------------------------------------------- > > (Updated July 19, 2012, 5:46 a.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9127:f00508d2c790 > --------------------------- > Clock: Move the clock and related functions to ClockedObject > > This patch moves the clock of the CPU, bus, and numerous devices to > the new class ClockedObject, that sits in between the SimObject and > MemObject in the class hierarchy. Although there are currently a fair > amount of MemObjects that do not make use of the clock, they > potentially should do so, e.g. the caches should at some point have > the same clock as the CPU, potentially with a 1:n ratio. This patch > does not introduce any new clock objects or object hierarchies > (clusters, clock domains etc), but is still a step in the direction of > having a more structured approach clock domains. > > The most contentious part of this patch is the serialisation of clocks > that some of the modules (but not all) did previously. This > serialisation should not be needed as the clock is set through the > parameters even when restoring from the checkpoint. In other words, > the state is "stored" in the Python code that creates the modules. > > The nextCycle methods are also simplified and the clock phase > parameter of the CPU is removed (this could be part of a clock object > once they are introduced). > > > Diffs > ----- > > src/arch/x86/interrupts.hh 48eeef8a0997 > src/arch/x86/interrupts.cc 48eeef8a0997 > src/arch/x86/utility.cc 48eeef8a0997 > src/cpu/BaseCPU.py 48eeef8a0997 > src/cpu/base.hh 48eeef8a0997 > src/cpu/base.cc 48eeef8a0997 > src/cpu/testers/memtest/memtest.hh 48eeef8a0997 > src/cpu/testers/networktest/networktest.hh 48eeef8a0997 > src/dev/CopyEngine.py 48eeef8a0997 > src/dev/Ethernet.py 48eeef8a0997 > src/dev/arm/RealView.py 48eeef8a0997 > src/dev/arm/pl111.hh 48eeef8a0997 > src/dev/arm/pl111.cc 48eeef8a0997 > src/dev/arm/timer_cpulocal.cc 48eeef8a0997 > src/dev/i8254xGBe.hh 48eeef8a0997 > src/dev/i8254xGBe.cc 48eeef8a0997 > src/dev/ns_gige.hh 48eeef8a0997 > src/dev/ns_gige.cc 48eeef8a0997 > src/dev/sinic.hh 48eeef8a0997 > src/dev/sinic.cc 48eeef8a0997 > src/mem/Bus.py 48eeef8a0997 > src/mem/MemObject.py 48eeef8a0997 > src/mem/bus.hh 48eeef8a0997 > src/mem/bus.cc 48eeef8a0997 > src/mem/mem_object.hh 48eeef8a0997 > src/mem/mem_object.cc 48eeef8a0997 > src/sim/ClockedObject.py PRE-CREATION > src/sim/SConscript 48eeef8a0997 > src/sim/clocked_object.hh PRE-CREATION > > Diff: http://reviews.gem5.org/r/1303/diff/ > > > Testing > ------- > > util/regress all passing (disregarding t1000 and eio) > > > Thanks, > > Andreas Hansson > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
