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

[Luke Yen <lyen@xxxxxxxxxxx>]

  There is a bug with the mfacet.py script 
in 1) reading the correct checkpoint for SMT and 2) setting the correct 
value for g_NUM_PROCESSORS when SMT is enabled.
   The main confusion arises because g_NUM_PROCESSORS has a different 
meaning in Ruby when SMT is used.  Under Ruby, g_NUM_PROCESSORS represents 
the PHYSICAL number of processors seen by the memory subsystem, not the 
LOGICAL number of processors.
  So let's take an example from below.

 2c_2p_4t      16              4               2               2

     You need to open a checkpoint that contains 16 (logical) processors. 
With 4 SMT threads/processor Ruby needs to build a memory subsystem for 4 
physical processors.  The memory subsystem doesn't care about how many 
HW thread contexts there are, just how many physical "driver" processors 
submit memory requests.  So set g_NUM_PROCESSORS in Ruby to 4
(i.e., LOGICAL_PROCESSORS/NUM_SMT_THREADS).

  These are the invariants:

   LOGICAL_PROCESSORS = number procs used to load the checkpoint
                      = g_NUM_SMT_THREADS*g_PROCS_PER_CHIP*g_NUM_CHIPS
   g_NUM_PROCESSORS = LOGICAL_PROCESSORS/g_NUM_SMT_THREADS

  When running with 1 SMT thread/processor, LOGICAL_PROCESSORS == 
g_NUM_PROCESSORS.
    I will add a wiki entry to the GEMS wiki to clarify this.

  Luke

On Wed, 15 Oct 2008, Fred A Bower wrote:

> 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
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.