> 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... > > Nathan Binkert wrote: > 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.
Does the kernel get notified when the frequency changes, or does it read it out of a register when it needs to know? The latter is easy, of course. - Steve ----------------------------------------------------------- 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
