On Wed, 5 May 2021, Vincent Donnefort wrote:
> Currently, _SC_NPROCESSORS_CONF is always equal to _SC_NPROCESSORS_ONLN.
> However, it is expected from the first one to give the total number of CPUs
> in the system, while the later must return only the number of CPUs which
> are currently online. This distinction is important for a software such as
> trace-cmd. Trace-cmd is a front-end for the kernel tracing tool ftrace.
> When recording traces, trace-cmd needs to get the total number of CPUs
> available in the system (_SC_NPROCESSORS_CONF) and not only the online ones
> otherwise if a CPU goes offline some data might be missing.
BTW, it looks like what trace-cmd actually needs is the "largest cpu id-number that could exist this boot" (as used by sched_getaffinity, pthread_setaffinity_np, etc.) rather than "total number of CPUs which could exist this boot".
Now, as far as I can tell _in practice_ the kernel always allocates "possible" cpu ids contiguously (so /sys/devices/system/cpu/possible will always contain e.g. "0-3", rather than something like "0,1,46,47"), but the data structures don't appear to require that. It's stored and reported as a bitmask. If Linux intends to guarantee that the "possible" bitset is (and will always) remain contiguous from 0, then the "largest" and "count" numbers are effectively equivalent, but otherwise they are not.
> Hence, add a specific method to get _SC_NPROCESSORS_CONF, based on the
> sysfs CPU entries /sys/devices/system/cpu/cpu[0-9]
Why do the opendir instead of reading from /sys/devices/system/cpu/possible?
The online/offline/possible CPU masks are documented in
linux/Documentation/ABI/testing/sysfs-devices-system-cpu and
linux/Documentation/cputopology.txt
The /sys/devices/system/cpu/cpuNN directories are created for every cpu in the "possible" bitmask, so those should be equivalent. I expect the reason glibc uses readdir is simply because "possible" was only introduced in Linux 2.6.26 in 2008.