This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: What *is* the API for sched_getaffinity? Should sched_getaffinity always succeed when using cpu_set_t?
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 22 Jul 2013 18:34:32 -0400
- Subject: Re: What *is* the API for sched_getaffinity? Should sched_getaffinity always succeed when using cpu_set_t?
- References: <51E42BFE dot 7000301 at redhat dot com> <51E4A0BB dot 2070802 at gmail dot com> <51E4A123 dot 9070001 at gmail dot com> <51E6F3ED dot 8000502 at redhat dot com> <51E6F956 dot 5050902 at gmail dot com> <51E714DE dot 6060802 at redhat dot com> <CAHGf_=oZW3kNA3V-9u+BZNs3tL3JKCsO2a0Q6f0iJzo=N4Wb8w at mail dot gmail dot com> <51E7B205 dot 3060905 at redhat dot com> <20130722214335 dot D9AFF2C06F at topped-with-meat dot com>
On 07/22/2013 05:43 PM, Roland McGrath wrote:
>> I can fix the glibc manual. A 'configured' CPU is one that the OS
>> can bring online.
>
> Where do you get this definition, in the absence of a standard that
> specifies _SC_NPROCESSORS_CONF? The only definition I've ever known for
> _SC_NPROCESSORS_CONF is a value that's constant for at least the life of
> the process (and probably until reboot) that is the upper bound for what
> _SC_NPROCESSORS_ONLN might ever report. If the implementation for Linux is
> inconsistent with that definition, then it's just a bug in the implementation.
Let me reiterate my understanding such that you can help me clarify
exactly my interpretation of the glibc manual wording regarding the
two existing constants.
The reality of the situation is that the linux kernel as an abstraction
presents the following:
(a) The number of online cpus.
- Changes dynamically.
- Not constant for the life of the process, but pretty constant.
(b) The number of configured cpus.
- The number of detected cpus that the OS could access.
- Some of them may be offline for various reasons.
- Changes dynamically with hotplug.
(c) The number of possible CPUs the OS or hardware can support.
- The internal software infrastructure is designed to support at
most this many cpus.
- Constant for the uptime of the system.
- May be tied in some way to the hardware.
On Linux, glibc currently maps _SC_NPROCESSORS_CONF to (b) via
/sys/devices/system/cpu/cpu*, and _SC_NPROCESSORS_ONLN to (a) via
/sys/devices/system/cpu/online.
The problem is that sched_getaffinity and sched_setaffinity only cares
about (c) since the size of the kernel affinity mask is of size (c).
What Motohiro-san was requesting was that the manual should make it clear
that _SC_NPROCESSORS_CONF is distinct from (c) which is an OS limit that
the user doesn't know.
We need not expose (c) as a new _SC_* constant since it's not really
required, since glibc's sched_getaffinity and sched_setaffinity could
hide the fact that (c) exists from userspace (and that's what I suggest
should happen).
Does that clarify my statement?
Cheers,
Carlos.