On Thu, 18 Jul 2013, Joel Hestness wrote:
Hi Nilay,
It looks like the Ruby unique IDs are only valid after instantiating all
Ruby controllers (see generated code calling
<MachineType>::getNumControllers() in build/*/mem/protocol/MachineType.cc),
which happens after writing SimObject parameters out to the config.ini file
(see src/python/m5/simulate.py:88-114). As such, to print the Ruby unique
IDs to the config.ini would require shuffling its printing to after
recursively calling createCCObject in simulate.py. This shuffling looks
like it would be non-trivial, especially since we'd need to update a Python
SimObject parameter for the Ruby unique ID in each controller.
I think Ruby should be assigning ids in python files and not in the
generated c++ code. Obviously, that would happen in a separate patch.
I also spent some more time digging into the use of cntrl_id, and the only
remaining use is in the CacheRecorder for checkpoint restore cache warmup.
It is used to identify the sequencer that a controller is attached to
during warmup, and the way it is organized now looks problematic to me.
There are cases where the number of sequencers/controllers may change from
a checkpoint run to the restored run (e.g. using accelerators configured
with different cache port configurations), so decreasing the number of
controllers from the checkpoint run can cause the warmup to fail if issuing
a warmup request to an cntrl_id that doesn't exist in the restore machine
(see m_seq_map use in src/mem/ruby/recorder/CacheRecorder.cc:91). I think
a better way to handle this is to use MachineType and version ID instead of
cntrl_id in the cache records to ensure that warmup packets are sent to not
only the right ID, but also the right MachineType. After all, it doesn't
make sense to warmup, say, a CPU cache with records that were attributed to
a DMA device in the checkpointed system due to cntrl_ids had been shifted
(this can result in hard-to-track/verify correctness and performance bugs
in warmup).
IIRC, the code assumes that there is a one-to-one mapping between the
sequencer of the checkpointed and the restored system and that the map is
actually just the identity map. I understand that this may not be true in
all cases. In fact, Jason has seen the problem you mention. We might want
to allow the case where the user can specify a mapping between the systems
and by default the mapping is assumed to be identity.
Is there a particular reason you'd prefer access to these IDs?
I think we do not want to store the MachineType in the checkpoint.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
