> 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?

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.


- Steve


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1221/#review3235
-----------------------------------------------------------


On Aug. 2, 2012, 2:35 p.m., Anthony Gutierrez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/1221/
> -----------------------------------------------------------
> 
> (Updated Aug. 2, 2012, 2:35 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Description
> -------
> 
> Changeset 9139:65fc52d74391
> ---------------------------
> 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 b4d0bdb5269420e4675d0aceff6f1392094a73f1 
>   src/arch/arm/table_walker.cc b4d0bdb5269420e4675d0aceff6f1392094a73f1 
>   src/cpu/base.cc b4d0bdb5269420e4675d0aceff6f1392094a73f1 
>   src/cpu/o3/commit_impl.hh b4d0bdb5269420e4675d0aceff6f1392094a73f1 
>   src/cpu/o3/cpu.cc b4d0bdb5269420e4675d0aceff6f1392094a73f1 
>   src/cpu/o3/fetch_impl.hh b4d0bdb5269420e4675d0aceff6f1392094a73f1 
>   src/cpu/o3/lsq_unit.hh b4d0bdb5269420e4675d0aceff6f1392094a73f1 
>   src/cpu/simple/timing.cc b4d0bdb5269420e4675d0aceff6f1392094a73f1 
>   src/dev/copy_engine.cc b4d0bdb5269420e4675d0aceff6f1392094a73f1 
>   src/dev/dma_device.cc b4d0bdb5269420e4675d0aceff6f1392094a73f1 
>   src/dev/i8254xGBe.cc b4d0bdb5269420e4675d0aceff6f1392094a73f1 
>   src/mem/bus.cc b4d0bdb5269420e4675d0aceff6f1392094a73f1 
>   src/mem/cache/base.cc b4d0bdb5269420e4675d0aceff6f1392094a73f1 
>   src/mem/packet_queue.cc b4d0bdb5269420e4675d0aceff6f1392094a73f1 
>   src/mem/port.hh b4d0bdb5269420e4675d0aceff6f1392094a73f1 
>   src/mem/port.cc b4d0bdb5269420e4675d0aceff6f1392094a73f1 
>   src/mem/ruby/system/RubyPort.cc b4d0bdb5269420e4675d0aceff6f1392094a73f1 
>   src/python/m5/simulate.py b4d0bdb5269420e4675d0aceff6f1392094a73f1 
>   src/sim/SConscript b4d0bdb5269420e4675d0aceff6f1392094a73f1 
> 
> 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

Reply via email to