[Gems-users] Chips, Processors, and Threads Configuration Rules

[Fred A Bower <fredb@xxxxxxxxxxx>]

I want to be certain that I am not doing something unsupported in my 
SMT-enabled CMP configurations.  As background, I would like to use Opal 
at times, so have created a set of Serengeti-based systems with UltraSPARC 
III+ processors.  The configurations I have are 2, 4, 8, 16, and 24 
processor machines, as 24 is the maximum supported by the Serengeti 
chassis (and therefore Simics for this CPU type, by my understanding).
What I would like to verify is what the configuration rules are around the
Ruby parameters for SMT and CMP systems.  The parameters in question are:

g_NUM_PROCESSORS
g_NUM_SMT_THREADS
g_PROCS_PER_CHIP
g_NUM_CHIPS

I think the largest confusing factor is the g_NUM_SMT_THREADS variable and 
how to treat it in relation to the number of processors in the Simics 
checkpoint.  For example, if I have my 16-processor checkpoint, are all of 
the following configurations legal for use with the checkpoint?
Config	g_NUM_PROCESSORS  g_NUM_SMT_THREADS  g_PROCS_PER_CHIP  g_NUM_CHIPS
1c_1p_16t	16		16		1		1
1c_2p_8t	16		8		2		1
2c_2p_4t	16		4		2		2

If so, is the correct interpretation that the invariants are:

g_NUM_PROCESSORS == Simics Checkpoint Processor Count
g_NUM_SMT_THREADS*g_PROCS_PER_CHIP*g_NUM_CHIPS == g_NUM_PROCESSORS

The pitfall I ran into is that mfacet.py sets g_NUM_PROCESSORS to 
chips*processors_per_chip and leaves smt_threads out of the calculation. 
The way I have my checkpoints loading now, this results in the wrong 
checkpoint getting loaded (and a SIGSEGV shortly thereafter in Ruby-only 
configurations).
If my reasoning is incorrect, can somebody please point me to the 
documentation to better explain the configuration rules/limits or provide 
a response here?
Thanks,
fred

Department of Computer Science, Duke University, 
Durham, NC 27708-0129 Email:  fredb@xxxxxxxxxxx