> On May 26, 2016, 6:16 a.m., Curtis Dunham wrote: > > src/arch/x86/tlb.cc, line 128 > > <http://reviews.gem5.org/r/3474/diff/1/?file=55457#file55457line128> > > > > If this just (essentially) copy constructs a new TLB from the old, why > > can't the same TLB be used .. just reconnecting the SimObject graph? > > Presumably so some form of generality could in theory be applied, or this > > was more expedient?... > > Jason Lowe-Power wrote: > I think I see what you're saying, but I'm not sure how it would be done > with the current "takeOverFrom" API. Could you describe in more detail what > you're envisioning? > > From what I understand, when switching CPUs, each object's "takeOverFrom" > method is called with a pointer to the old version of the object. Do you > think this should be changed? > > Curtis Dunham wrote: > I'm not sure it should be changed, just calling it into question in this > case -- because what is this function doing that wouldn't have the same > result as just using the same TLB instance? I suspect it comes down to the > way the object graph is constructed, as a matter of gem5 philosophy, and how > that has been integrated with the "switcheroo" functionality. I'm not sure > it's worth opening that can of worms, unless we have a better solution. One > thing to consider though: generally speaking, would we want to do such a > copying when the std::type_info (return value of typeid(T)) for the two > objects is the same? Different hacker-speak terminology at the Python/SWIG > level, but same argument. > > Jason Lowe-Power wrote: > I guess it's possible that you would have a different TLB model for your > detailed simulation vs. warmup. That would be a reason to use the > "takeOverFrom" method instead of just switching the pointers or doing an > automatic deep copy via type_info (if that's what you're proposing). Though > that clearly isn't the case currently. > > Can we drop this issue for now? > > Curtis Dunham wrote: > Dropped, thanks for the discussion.
Actually I came to raise the same issue---instead of copying the state, why doesn't the CPU's takeOverFrom() method just copy the TLB pointers? This is basically what we do with caches, IIRC. While in theory you could have different TLB configs between warmup and simulation, to be honest I don't see a situation where that makes sense (just as is the case for caches). - Steve ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/3474/#review8346 ----------------------------------------------------------- On May 20, 2016, 3:09 p.m., Jason Lowe-Power wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/3474/ > ----------------------------------------------------------- > > (Updated May 20, 2016, 3:09 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > Changeset 11482:51dec612f11b > --------------------------- > cpu, x86: Allow the TLB to be warmed up before CPU switch > > Previously, before a CPU was switched out, the TLB was always flushed > Now, we first call takeOverFrom with the TLB. We only flush > the TLB right before the CPU is switched in. > This changeset also contains the needed code for x86 to > takeOverFrom with the TLB, similar changes may be needed for the ARM > architecture. > With this changeset, when you switch from atomic to timing mode the > TLB is warm. > > > Diffs > ----- > > src/arch/x86/tlb.hh fc247b9c42b6 > src/arch/x86/tlb.cc fc247b9c42b6 > src/cpu/base.cc fc247b9c42b6 > > Diff: http://reviews.gem5.org/r/3474/diff/ > > > Testing > ------- > > > Thanks, > > Jason Lowe-Power > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
