Documentation tells me that sysconf(_SC_NPROCESSORS_CONF) get_nprocs_conf() gives me the upper bound of CPUs and sysconf(_SC_NPROCESSORS_ONLN) get_nprocs() gives the currently online CPUs. get_nprocs_conf seems to return "possible" value, and it seems like the value is 32 on my system. However from reading Documentation/ABI/testing/sysfs-devices-system-cpu "present" might be more suited instead of "possible". (the value used to be 12 on bullseye kernel, and bookworm kernel started reporting 32 for possible, which maybe possible but not very useful as only 12 is present on my system.) I think one of the following could be useful - use "present" instead of possible for get_nprocs_conf - update get_nprocs_conf to document that it's a theoretical value and not the number of present cpus. - introduce another API for the present CPUs that may or may not be online.
Hi, That is correct, at least when /sys is mounted. I am not convinced about that. As you said above, the _SC_NPROCESSORS_CONF should gives the upper bound of CPUs. Using "present" means this is not guaranteed anymore, so a process allocating structures for "present" CPUs might fail, because at some point there might be more "online" CPU than "present" CPU in the past. Of course such a thing will not happen on your laptop, but it might happen in the context of virtualisation where CPUs could be added dynamically (in addition to bringing some cores from offline to online). As said above I don't think this is correct. I agree this could be updated, probably using the same terminology as in Documentation/ABI/testing/sysfs-devices-system-cpu. Adding a newer API is something possible, but needs to be coordinated with upstream. For that the use case should be clearly defined. Regards Aurelien
Hi, That is correct, at least when /sys is mounted. I am not convinced about that. As you said above, the _SC_NPROCESSORS_CONF should gives the upper bound of CPUs. Using "present" means this is not guaranteed anymore, so a process allocating structures for "present" CPUs might fail, because at some point there might be more "online" CPU than "present" CPU in the past. Of course such a thing will not happen on your laptop, but it might happen in the context of virtualisation where CPUs could be added dynamically (in addition to bringing some cores from offline to online). As said above I don't think this is correct. I agree this could be updated, probably using the same terminology as in Documentation/ABI/testing/sysfs-devices-system-cpu. Adding a newer API is something possible, but needs to be coordinated with upstream. For that the use case should be clearly defined. Regards Aurelien