identifying cpus (and smt threads)
R Sharada
sharada at in.ibm.com
Thu Jul 22 22:56:10 EST 2004
Hello,
I am trying to remove some initialization code of the cpumask global
data structures from the prom_hold_cpus code and had a few queries.
The four cpu maps are the following:
- cpu_online_map,
- cpu_available_map,
- cpu_possible_map, and
- cpu_present_at_boot_map
This is my understanding of the prom_hold_cpus code and mask initialization:
Each device_tree node of type cpu represents a physical processor/cpu
For each valid processor identified by the firmware (obtained from looking at
the 'status' property of the device_tree cpu node)
Get the 'reg' property that represents the physical cpu id
Get the 'interrupt-server#s' property that is supposed to represent
something about the smt threads, if supported
(what does this property actually mean? On my Power4 test machine, p630,
I found this property seems to be the same as the 'reg' property in the open
firmware prompt. Does it give the individual thread ids, if SMT is supported?).
I tried to find concrete information about this property in documents, but
failed to get it.
Based on the propsize returned from the getprop for the property
ibm,interrupt-server#s', the number of threads (CPU_MAX_THREADS is anyways 2) is
obtained.
The code then differentiates between the primary thread of boot cpu and
non-boot cpu.
If primary thread of boot cpu, then set the cpuid in all the 4 cpumasks.
If primary thread of non-boot cpu, then make them spin on secondary-hold
and when they are out, set the cpuid in the cpu_avaiable_map, cpu_possible_map
and cpu_present_at_boot. But they are not set in the cpu_online_map. Why is
that? Aren't they online if they have come out of the secondary_hold spinloop?
Then the secondary threads cpuids are set in the cpu_available_map and
cpu_present_at_boot map.
Later, in setup_system, the secondary threads are started through the
rtas-call 'start-cpu' if they are already in the cpu_available_map but not on
the cpu_possible_map.
A few questions here:
- why is there a cpu_present_at_boot map? It seems to be the same as the
cpu_available_map. Or did I miss something?
- second, I want to move the cpuset() calls for setting the cpumasks from the
prom_hold_cpus code to setup_system. However, I see that only the primary thread
of boot cpu is set in the cpu_online_map, and the primary threads of non-boot
cpus are not set in the cpu_online_map.
- When do the other primary threads of the non-boot cpus get set in the
online_map? Can I assume that they will all be up by the time setup_system is
executed and set all the primary threads in the cpu_online_map? If not, how can
I differentiate between the primary threads of the boot and non-boot cpus?
Thanks and Regards,
Sharada
** Sent via the linuxppc64-dev mail list. See http://lists.linuxppc.org/
More information about the Linuxppc64-dev
mailing list