> On Aug. 8, 2012, 11:24 a.m., Steve Reinhardt wrote: > > src/cpu/base.cc, line 460 > > <http://reviews.gem5.org/r/1221/diff/9/?file=28446#file28446line460> > > > > This fancy footwork with the cpuId value deserves a comment, I think... > > Anthony Gutierrez wrote: > Ok, I can add a comment. > > But, I did have a question about the need for copying over the cpuId. > Formerly it was simply copied over, meaning after one switch both CPUs would > always have the same ID. And to me this makes sense, since from an OS > perspective they are essentially the same CPU. From the simulator's view > there may be reasons for the CPU and its switched-out equivalent to have > unique IDs but I don't know of any. Would it be better to just have any CPU > and its equivalent have the same ID? > > Steve Reinhardt wrote: > I don't know either... I assumed that you did it this way because there > was some bug you ran into that required you to do this (which is why I was > looking for a comment to explain what it was). I think you should do the > simplest thing that works. In the long run, it would be good to have the > python config script just set all the cpus that we'll be switching in and out > of the same spot to have the same cpuId in the first place, then we cold just > have an assertion in the C++ to guarantee that the configuration isn't messed > up. I don't know if it's worth trying to do that now or if it's best left > for a later patch.
I removed the CPU id copying. I also updated my config patch to set all "switched out" CPUs to share the id of their active equivalent CPU. - Anthony ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1221/#review3235 ----------------------------------------------------------- On Aug. 8, 2012, 9:17 p.m., Anthony Gutierrez wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1221/ > ----------------------------------------------------------- > > (Updated Aug. 8, 2012, 9:17 p.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9148:46b12c142135 > --------------------------- > O3,ARM: fix some problems with drain/switchout functionality and add Drain > DPRINTFs > > This patch fixes some problems with the drain/switchout functionality > for the O3 cpu and for the ARM ISA and adds some useful debug print > statements. > > This is an incremental fix as there are still a few bugs/mem leaks with the > switchout code. Particularly when switching from an O3CPU to a > TimingSimpleCPU. However, when switching from O3 to O3 cores with the ARM ISA > I haven't encountered any more assertion failures; now the kernel will > typically panic inside of simulation. > > > Diffs > ----- > > src/arch/arm/table_walker.hh 05137f17887eec174fc7706ebe6295992636b8dc > src/arch/arm/table_walker.cc 05137f17887eec174fc7706ebe6295992636b8dc > src/cpu/base.cc 05137f17887eec174fc7706ebe6295992636b8dc > src/cpu/o3/commit_impl.hh 05137f17887eec174fc7706ebe6295992636b8dc > src/cpu/o3/cpu.cc 05137f17887eec174fc7706ebe6295992636b8dc > src/cpu/o3/fetch_impl.hh 05137f17887eec174fc7706ebe6295992636b8dc > src/cpu/o3/lsq_unit.hh 05137f17887eec174fc7706ebe6295992636b8dc > src/cpu/simple/timing.cc 05137f17887eec174fc7706ebe6295992636b8dc > src/dev/copy_engine.cc 05137f17887eec174fc7706ebe6295992636b8dc > src/dev/dma_device.cc 05137f17887eec174fc7706ebe6295992636b8dc > src/dev/i8254xGBe.cc 05137f17887eec174fc7706ebe6295992636b8dc > src/mem/bus.cc 05137f17887eec174fc7706ebe6295992636b8dc > src/mem/cache/base.cc 05137f17887eec174fc7706ebe6295992636b8dc > src/mem/packet_queue.cc 05137f17887eec174fc7706ebe6295992636b8dc > src/mem/port.hh 05137f17887eec174fc7706ebe6295992636b8dc > src/mem/port.cc 05137f17887eec174fc7706ebe6295992636b8dc > src/mem/ruby/system/RubyPort.cc 05137f17887eec174fc7706ebe6295992636b8dc > src/sim/SConscript 05137f17887eec174fc7706ebe6295992636b8dc > > Diff: http://reviews.gem5.org/r/1221/diff/ > > > Testing > ------- > > > Thanks, > > Anthony Gutierrez > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
