Red Hat Bugzilla – Bug 157909
[RHEL4] _SC_NPROCESSORS_CONF counts active CPUs
Last modified: 2016-11-24 10:49:45 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.7) Gecko/20050416 Fedora/1.0.3-1.3.1 Firefox/1.0.3
Description of problem:
sysconf(_SC_NPROCESSORS_CONF) should return the number of available processors. But with the exception of alpha and sparc, it returns the same value as sysconf(_SC_NPROCESSORS_ONLN), namely the number of CPU entries in /proc/stat or in /proc/cpuinfo -- both of which only contain active CPUs.
This is wrong with hotplug CPUs, which are now enabled on ppc64.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Configure a pSeries LPAR with partition_active_processors < partition_potential_processors.
2. Run getconf _NPROCESSORS_ONLN
3. Run getconf _NPROCESSORS_CONF
Actual Results: For partition_active_processors=2, partition_potential_processors=5 with SMT, I get 4 and 4.
Expected Results: 4 and 10.
Created attachment 114452 [details]
This patch solved the problem for me
Not sure if this ought to be done for all arches that don't define
GET_NPROCS_CONF_PARSER or just ppc*.
In any case, I think it would be better to move the common code from
get_proc_path and get_sys_path in a separate helper routine to avoid code
Agreed regarding code duplication. I didn't do it because I'd never coded for
glibc before and was afraid I'd get something wrong; this was more of a proof of
As of now, ppc64 is the only arch that's built with CONFIG_HOTPLUG_CPU=y in
RHEL4, so it's the only one that will be affected. But I would expect hotplug
CPUs to become enabled for more arches eventually (SLES9 SP1 already enables
them for s390*), and then it will apply to those arches, too. On the other
hand, ppc64 also seems to be the only one where the kernel bothers to set up
cpu_possible_map according to hardware availability. Everywhere else,
num_possible_cpus() == NR_CPUS, and with hotplug enabled,
/sys/devices/system/cpu will contain NR_CPUS entries. So the question is, what
SHOULD get_nprocs_conf() return on such a system. I think returning NR_CPUS is
more correct than returning a variable number when the OS doesn't know any
better, but reasonable people can disagree about this. Ideally, of course, the
kernel should implement more accurate cpu_possible_map setup before enabling
hotplug CPUs for an arch.
I have implemented something similar a few weeks ago. I didn't know your code
back then and it's quite a bit different and more robust. We can assume the
sysfs is mounted at /sys which is why I don't but any effort into finding it.
It's up to Jakub to backport it to RHEL. The code is available now in
rawhide, the code which will be in F8.
This is not going to be fixed in RHEL 4. However, it was fixed in RHEL 5.7.