From: Elad Lahav <elahav@xxxxxxxxxxxx> Date: Fri, 12 Sep 2008 20:47:24 -0400 > > The kernel treats core_id==0 as special, therefore we start the > > indexes there at "1". > > The kernel treats proc_id=-1 as special, therefore we start those > > indexes at "0". > > My problem was not with the indexing, but rather with the meaning of > proc_id. It's neither the physical processor ID, nor the virtual > processor ID. It's just a one-to-one mapping of the core ID. As the > virtual processor ID is the same as the kernel's CPU ID, I think > that proc_id should hold the physical processor ID. If not, than > this information should be kept in some other field of cpu_data. For a cpu such as Niagara T1, the proc_id and core_id will represent the same thing. Niagara T1 comes only in single socket variants. For Niagara T2, which can be multisocket, core_id and proc_id can be different. Look at how this information is obtained from the machine description in arch/sparc64/kernel/mdesc.c, and then look at how it is used to build the sibling and core cpu maps, which are used to build the scheduling domain datastructures in kernel/sched.c If afterwards you think there is still some problem, thene please describe a discrete issue you thing arises because of how these values are set. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
