Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 157909 - [RHEL4] _SC_NPROCESSORS_CONF counts active CPUs
Summary: [RHEL4] _SC_NPROCESSORS_CONF counts active CPUs
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glibc
Version: 4.0
Hardware: powerpc
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Jeff Law
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-05-16 22:31 UTC by Lev Makhlis
Modified: 2016-11-24 15:49 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-01-25 04:35:22 UTC


Attachments (Terms of Use)
This patch solved the problem for me (deleted)
2005-05-16 22:33 UTC, Lev Makhlis
no flags Details | Diff

Description Lev Makhlis 2005-05-16 22:31:35 UTC
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 22:33:26 UTC
Created attachment 114452 [details]
This patch solved the problem for me

Comment 2 Jakub Jelinek 2005-05-19 14:37:53 UTC
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 15:16:27 UTC
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 15:59:13 UTC
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-25 04:35:22 UTC
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.