What *is* the API for sched_getaffinity? Should sched_getaffinity always succeed when using cpu_set_t?

[KOSAKI Motohiro]

(7/17/13 3:43 PM), Carlos O'Donell wrote:
> On 07/15/2013 09:25 PM, KOSAKI Motohiro wrote:
>> I meant, _SC_NPROCESSORS_ONLN is racy and not recommended if cpu hotplug is happen.
>
> (1) Race-free fix.
>
> Given that it's racy to use _SC_NPROCESSORS_ONLN, and it's also racy
> to rely on sched_getaffinity returning EINVAL, the best we can do is
> add a _SC_NPROCESSORS_MAX_NP and use that to query the maximum number
> of processors the OS supports and use that.

No. sched_getaffinity is not racy because it uses possible cpus instead
of online cpus. Because Ulrich Drepper requested me so when I implement current
kernel logic.


> (2) Accept the race exist and live with it.
>
> Accept that sched_getaffinity may take an infinite amount of time as
> it attempts to query the kernel's cpu affinity mask size (via sys or
> some other means) and then get the affinity mask. It insulates the user
> from writing such code, and if you aren't plugging in and out cpus
> continually it should succeed at some point.
>
> This solution does not requires a new non-portable sysconf value.
> The use of sched_setaffinity may still fail if cpus were taken offline
> and the user at that point has to call sched_getaffinity again and
> try again. It is documented that sched_setaffinity might fail with
> EINVAL in this case.

Hmmm...
Sorry, I haven't caught the point. If user uses _SC_NPROCESSORS_ONLN
sched_getaffinity() may always fail because it uses possible cpus
internally.

Example:

online cpus: 0-1023
possible cpus: 0-4095

and, if the user allocate and uses 1024bit width bitmap, sched_getaffinity() always
fail even though he doesn't use hot plugging. So, this is not only race matter.



> (3) Accept the interface as it is today.
>
> Both sched_getaffinity and sched_setaffinity can fail with EINVAL
> at any time and you need to adjust the call to succeed. Code that
> uses a fixed cpu_set_t might never work correctly.
>
> Perhaps the most important question is:
>
> Should sched_getaffinity be able to fail with EVINAL and what does
> that mean?
>
> My opinion is that is should not, and that such internal kernel
> details should be kept out of the API. It should just copy whatever
> size the user has.
>
> It should be OK to use _SC_NPROCESSORS_ONLN here, but we can document
> that it's racy in the presence of hot plug.
>
> We can document the new _SC_NPROCESSORS_MAX_NP as a non-portable way
> to get the OS configured maximum which you can use if you want to get
> all possible CPUs.

I hope to clarify the meanings of _SC_NPROCESSORS_CONF at first. I'm still
unclear we need to make new _SC_NPROCESSORS_MAX_NP.