Display online cpus value in preference to kt->cpus
crash 5.0.0 introduced a change to ppc64_paca_init() in ppc64.c to
manipulate kt->cpus to fix a 4.0-8.11 regression when
cpu_possible_map has more cpus than cpu_online_map. The change basically
adjusts kt->cpus to the highest cpu index + 1. In situations where cpus
from 0 through highest index are all online, this will equal online cpus.
On IBM POWER based system supporting SMT, we can have it dynamically
enabled and disabled and so we can go from:
kernel_init() initially does come up with 5 for kt->cpus initially before
the machdep init routine (ppc64_paca_init) ends up changing it to 9 in
the above situation.
Because of the way other parts of the code seem to iterate, allowing kt->cpus
to get set to the number of online cpus (5) would make them not work properly
either. Case in point, the ps command. It would iterate through the first 5
cpus for the swapper tasks and stop, providing no information for swapper tasks
on online cpus 6 and 8.
Rather than displaying kt->cpu for cpu count to display to users, can we call
get_cpus_online() itself. This will solve the problem of keeping kt->cpu
separate from get_cpus_online(). So commands like ps, set etc can still rely on
kt->cpu as set for each architecture. Additionally, we need to consider
providing the value as it exists after machine dependent init in case
the symbols required by get_cpus_online() are not available.
The patch provided creates a new routine called get_cpus_to_display() in
kernel.c that simply attempts to retrieve the count of
online CPUs with get_cpus_online(). However, since the cpu_online_map symbol
may not be available with all kernels, the cpus_to_display() routine will
return the value for kt->cpus if get_cpus_online() return 0 for that case
to maintain backwards compatibility.
With this in mind, all locations (mainly the display_machine_stats() routines
for each architecture, display_sys_stats() and dump_kernel_table()) in the
source that would print the cpu count using kt->cpus now call
get_cpus_to_display() to obtain that value.
This should hopefully provide the user with an expected CPU count regardless of
the internal manipulation that is sometimes done to the kt->cpus value.
Luciano Chavez <email@example.com>
IBM Linux Technology Center