Hi, On 2023-06-17 21:19, Junichi Uekawa wrote: > > Package: libc6 > Version: 2.36-9 > > 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
That is correct, at least when /sys is mounted. > 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 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). > I think one of the following could be useful > > - use "present" instead of possible for get_nprocs_conf As said above I don't think this is correct. > - update get_nprocs_conf to document that it's a theoretical value and not > the number of present cpus. I agree this could be updated, probably using the same terminology as in Documentation/ABI/testing/sysfs-devices-system-cpu. > - introduce another API for the present CPUs that may or may not be online. 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 -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://aurel32.net
