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


Date: Fri, 11 Jun 2010 16:46:17 +0800
From: Amy Pang <pangjiufeng@xxxxxxxxxxxxxxx>
Subject: [Gems-users] proc_num, sim_proc_num,core_num, thread_num
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
[← Prev in Thread] Current Thread [Next in Thread→]