Bug 157909 - [RHEL4] _SC_NPROCESSORS_CONF counts active CPUs
[RHEL4] _SC_NPROCESSORS_CONF counts active CPUs
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glibc (Show other bugs)
4.0
powerpc Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Law
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-05-16 18:31 EDT by Lev Makhlis
Modified: 2016-11-24 10:49 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-01-24 23:35:22 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
This patch solved the problem for me (4.00 KB, patch)
2005-05-16 18:33 EDT, Lev Makhlis
no flags Details | Diff

  None (edit)
Description Lev Makhlis 2005-05-16 18:31:35 EDT
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):
glibc-2.3.4-2

How reproducible:
Always

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.

Additional info:
Comment 1 Lev Makhlis 2005-05-16 18:33:26 EDT
Created attachment 114452 [details]
This patch solved the problem for me
Comment 2 Jakub Jelinek 2005-05-19 10:37:53 EDT
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
duplication.
Comment 3 Lev Makhlis 2005-05-19 11:16:27 EDT
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
concept.

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.
Comment 4 Ulrich Drepper 2007-08-25 11:59:13 EDT
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[45].  The code is available now in
rawhide, the code which will be in F8.
Comment 6 Jeff Law 2012-01-24 23:35:22 EST
This is not going to be fixed in RHEL 4.  However, it was fixed in RHEL 5.7.

Note You need to log in before you can comment on or make changes to this bug.