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: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Tue, 16 Jul 2013 11:43:30 -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> <20130716134700 dot GN29800 at brightrain dot aerifal dot cx>
>> >sysconf(_SC_NPROCESSORS_ONLN) returns number of online cpus. not possible cpus.
>> >
>> >online cpus: number of _now_ onlined cpus
>> >possible cpus: number of maximum cpus on the system. (i.e. depend on arch and
>> >firmware and ACPI table)
>> >
>> >/sys/devices/system/cpu/possible returns possible cpu mask. AFAIK, unfortunately,
>> >sysconf() doesn't support to get possible cpus.
>>
>> I meant, _SC_NPROCESSORS_ONLN is racy and not recommended if cpu hotplug is happen.
>
> This race makes me think having sched_getaffinity always succeed may
> be a bad idea; there's no way to work around the race.
Why? I couldn't get your point. Again,
/sys/devices/system/cpu/possible is a race free and kernel
uses it internally.
> What if it only
> succeeded when the current number of cpus online (as opposed to the
> kernel limit) is smaller than the cpuset?
This only changes the threshold, not solve. I can imagine many machine
will have >1000
cpus 10 years later.
> glibc could work around old
> kernels that fail in the latter case by, in the EINVAL failure path,
> trying again to get the whole cpuset to its own buffer and then
> copying that back to the caller's buffer if it fits.
Sorry. What is the latter case?