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: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>
- To: Tolga Dalman <tolga dot dalman at googlemail dot com>, Carlos O'Donell <carlos at redhat dot com>, Roland McGrath <roland at hack dot frob dot com>
- Cc: mtk dot manpages at gmail dot com, KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>, libc-alpha <libc-alpha at sourceware dot org>, linux-man at vger dot kernel dot org
- Date: Tue, 21 Jul 2015 17:03:18 +0200
- Subject: Re: What *is* the API for sched_getaffinity? Should sched_getaffinity always succeed when using cpu_set_t?
- Authentication-results: sourceware.org; auth=none
- 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> <51EDB378 dot 8070301 at redhat dot com> <558D6171 dot 1060901 at gmail dot com> <558DB0A0 dot 2040707 at gmail dot com> <5591BB55 dot 5080605 at googlemail dot com>
Hello Tolga,
On 06/29/2015 11:40 PM, Tolga Dalman wrote:
> Michael,
>
> given the approach is accepted by Carlos and Roland, I have
> some minor textual suggestions for the patch itself.
>
> On 06/26/2015 10:05 PM, Michael Kerrisk (man-pages) wrote:
>> --- a/man2/sched_setaffinity.2
>> +++ b/man2/sched_setaffinity.2
>> @@ -223,6 +223,47 @@ system call returns the size (in bytes) of the
>> .I cpumask_t
>> data type that is used internally by the kernel to
>> represent the CPU set bit mask.
>> +.SS Handling systems with more than 1024 CPUs
>
> What if the system has exactly 1024 CPUs ?
> Suggestion: systems with 1024 or more CPUs
I think you've missed something here. CPUs are numbered starting at 0.
"more than 1024 CPUs" is correct here, I belive.
>
>> +The
>> +.I cpu_set_t
>> +data type used by glibc has a fixed size of 128 bytes,
>> +meaning that the maximum CPU number that can be represented is 1023.
>> +.\" FIXME . See https://sourceware.org/bugzilla/show_bug.cgi?id=15630
>> +.\" and https://sourceware.org/ml/libc-alpha/2013-07/msg00288.html
>
> No objection, although I have never really noticed external references
> in man-pages (esp. web refs). Shouldn't these be generally avoided ?
> (and yes, I have noticed the FIXME)
Those pieces are comments in the page source (not rendered by man(1)).
>> +If the system has more than 1024 CPUs, then calls of the form:
>
> 1024 or more CPUs.
See above
>> +
>> + sched_getaffinity(pid, sizeof(cpu_set_t), &mask);
>> +
>> +will fail with the error
>> +.BR EINVAL ,
>> +the error produced by the underlying system call for the case where the
>> +.I mask
>> +size specified in
>> +.I cpusetsize
>> +is smaller than the size of the affinity mask used by the kernel.
>> +.PP
>> +The underlying system calls (which represent CPU masks as bit masks of type
>> +.IR "unsigned long\ *" )
>> +impose no restriction on the size of the mask.
>> +To handle systems with more than 1024 CPUs, one must dynamically allocate the
>> +.I mask
>> +argument using
>> +.BR CPU_ALLOC (3)
>
> I would rewrite the sentence to avoid "one must".
This is a "voice" thing. I personally find "one must" is okay.
>> +and manipulate the mask using the "_S" macros described in
>
> and manipulate the macros ending with "_S" as described in
I think you've misread the text. I think it's okay.
>> +.BR CPU_ALLOC (3).
>> +Using an allocation based on the number of online CPUs:
>> +
>> + cpu_set_t *mask = CPU_ALLOC(CPU_ALLOC_SIZE(
>> + sysconf(_SC_NPROCESSORS_CONF)));
>> +
>> +is probably sufficient, although the value returned by the
>> +.BR sysconf ()
>> +call can in theory change during the lifetime of the process.
>> +Alternatively, one can obtain a value that is guaranteed to be stable for
>
> Like above, I would replace "one can obtain a value" by "a value can be obtained".
See above.
>> +the lifetime of the process by proby for the size of the required mask using
>
> s/proby/probing/.
Thanks--I'd already spotted that one and fixed.
>> +.BR sched_getaffinity ()
>> +calls with increasing mask sizes until the call does not fail with the error
>> +.BR EINVAL .
>
> I would replace "until the call does not fail with error ..." by "while the call succeeds".
I think you've misunderstood the logic here... Take another look at the sentence.
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/