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

["Carlos O'Donell" <carlos at redhat dot com>]

On 07/17/2013 06:56 PM, KOSAKI Motohiro wrote:
>> Thank you for the clarification.
>>
>> I think I see what you mean.
>>
>> There is no race.
>>
>> (1) No race in sched_getaffinity internally.
>>
>> Just to clarify:
>>
>> kernel/sched/core.c:
>> ...
>> 3714 SYSCALL_DEFINE3(sched_getaffinity, pid_t, pid, unsigned int, len,
>> 3715                 unsigned long __user *, user_mask_ptr)
>> ...
>> 3720         if ((len * BITS_PER_BYTE) < nr_cpu_ids)
>> 3721                 return -EINVAL;
>>
>> This code causes EINVAL to be returned when the length of the userspace
>> buffer is smaller than the size of the mask for ONLINE cpus.
> 
> No. nr_cpu_ids mean possible cpus. This code mean, if user buffer is less than
> possible cpus, sched_getaffinity() always return EINVAL.
> I agree this name is not fully clear. ;-)

OK, thank you for clarifying. In which case all of my further assumptions
are wrong.
 
> btw, we don't call memset(0) for clearing rest buffer because backward
> compatibility. gibc need to clear it if needed.
 
glibc will clear it. 
 
>> You might have an empty socket with no configured CPU and
>> that would contribute towards possible cpus, but not configured
>> or online cpus.
> 
> If 'configured' is such mean, you are correct. And then, we need to fix glibc
> manual for clarify.
 
I can fix the glibc manual. A 'configured' CPU is one that the OS
can bring online.
 
>> It really seems to me that we need _SC_NPROCESSORS_MAX_NP to
>> indicate the physical maximum number of CPUs the OS can connect
>> given a particular topology, and it can return -1 to indicate
>> it is completely a dynamic topology in which case all we can
>> do is call sched_getaffinity with higher and higher buffers
>> to find the current maximum (and we can't cache it).
> 
> Right.
> 
>> Does that clarify why I think we may need _SC_NPROCESSORS_MAX_NP?
> 
> Yes, completely. My question was, current glibc manual describe
> sysconf (_SC_NPROCESSORS_CONF) mean "To determine the number of
> processors available to the system one can run". And, if "can" mean
> hot plugging, it should
> be possible cpus. It was my point.

No, it needs clarification. I will fix the manual.

Either way the question remains:

(1) Should glibc's sched_getaffinity never fail?

or

(2) Should glibc's sched_getaffinity fail with EINVAL when the size
of the cpu set is smaller than the size of the affinity mask for
all possible cpus?

I believe that a call to sched_getaffinity should not fail.

What do you think?

Cheers,
Carlos.