Yes, you need to set Ruby to be the number of physical procs you want to
simulate (i.e. 8). This is also done as part of the mfacet.py script. I
believe there's a config variable in Ruby called g_numSMTProcs for this
purpose.
The numbering that you mentioned is normal and is how Opal calculates
IDs internally for its physical procs under SMT.
Luke
On Tue, 9 Sep 2008, Daniel Sánchez Pedreño wrote:
Ok, but now another assert fails:
*system/system.C:1790: static integer_t system_t::rubyInstructionQuery(int):
Assertion `(seq_index >= 0 && seq_index < system_t::inst->m_numSMTProcs)'
failed*
I'm simulating a benchmark with 16 application threads with 2-thread
processors; when this asser fails seq_index is equal to 8 while m_numProcs
is 16 and m_numSMTProcs is 8.
I think that the problem is that Ruby should work with 8 processors instead
of 16. I have solved this issue by setting the number of processors to 8
(instead of 16 and everything looks ok). Is normal that the identifier for
the physical processors will be 0, 2, 4, 6, 8, 10, 12 and 14 for 16
application threads)?
Thank you.
|