Re: [Gems-users] proc_num, sim_proc_num,core_num, thread_num

[Amy Pang <pangjiufeng@xxxxxxxxxxxxxxx>]

Hi,

I run the simulation in GEMS, and find these problems. Could anybody give me some hints about that? Thanks a lot.

2010/6/11 Amy Pang <pangjiufeng@xxxxxxxxxxxxxxx>

Hi,

I have a question about the calculation of three variable: proc_num, sim_proc_num, core_num, thread_num.

 In GEMS, proc_num = SIMICS_current_processor_number(), it is the logical processor number in the system.

1. sim_proc_num = proc_num / g_NUM_SMT_THREADS, it is the physical processor number in the system
2. core_num = (proc_num / g_NUM_SMT_THREADS) % g_PROCS_PER_CHIP, it is the core number in a chip (starting from 0, and less than g_PROCS_PER_CHIP)
3. thread_num = proc_num / g_NUM_SMT_THREADS, it is the thread number in a physical processor (starting from 0, and less than g_NUM_SMT_THREADS)
   

 And $GEMS/ruby/simics/commonds.C line 232~234 confirms my idea.But  $GEMS/ruby/rock/Rock.C line 192 calculates thread_num differently (thread_no = core_no % g_NUM_SMT_THREADS), Is it a bug in GEMS? What does thread_num mean in this function?For example, if we have two chip, four processors per chip, two SMT threads per processors. proc_no(11) is in chip_no 1, core_no 1. But thread_no is 1 according to the $GEMS/ruby/rock/Rock.C line 192. In fact proc_no(11) is the first thread in the core_no(1) and the thread_no should be 0.

How many logical processors are supported by GEMS at most currently?  Those have gone through many tests. 16, 32 or 64?

Thanks for your reply.
--
-Amy Pang

-- 
-Amy Pang