This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] glibc: Remove CPU set size checking from affinity functions [BZ #19143]
- From: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: mtk dot manpages at gmail dot com, GNU C Library <libc-alpha at sourceware dot org>
- Date: Thu, 10 Mar 2016 18:07:09 +0100
- Subject: Re: [PATCH] glibc: Remove CPU set size checking from affinity functions [BZ #19143]
- Authentication-results: sourceware.org; auth=none
- References: <5621126E dot 5080801 at redhat dot com> <56252723 dot 6010407 at redhat dot com> <562A3D82 dot 5010907 at redhat dot com> <563A67D3 dot 5070306 at redhat dot com> <565492BA dot 2030006 at redhat dot com> <CALxWeYqvcgRMmsY7NAROpcHjywtsvEXynTN0ZrqKgdH40g0FUw at mail dot gmail dot com> <56DEB4D3 dot 6020202 at redhat dot com> <56DF2B0C dot 402 at gmail dot com> <56E15885 dot 80708 at redhat dot com>
Hello Florian.
On 03/10/2016 12:20 PM, Florian Weimer wrote:
> On 03/08/2016 08:42 PM, Michael Kerrisk (man-pages) wrote:
>
>>> One caveat is that sched_getaffinity can set bits beyond the requested
>>> allocation size (in bits) because the kernel gets a padded CPU vector
>>> and sees a few additional bits.
>>
>> I'm not quite clear on this point. Does it get a padded CPU vector
>> because CPU_ALLOC() might allocate a vector of size larger than the
>> user requested?
>
> Yes, this is the problem, combined with CPU_ALLOC_SIZE returning the
> larger size (which is unavoidable).
Thanks for the clarification. I added this paragraph:
Be aware that CPU_ALLOC(3) may allocate a slightly larger CPU
set than requested (because CPU sets are implemented as bit
masks allocated in units of sizeof(long)). Consequently,
sched_getaffinity() can set bits beyond the requested allocaâ
tion size, because the kernel sees a few additional bits.
Therefore, the caller should iterate over the bits in the
returned set, counting those which are set, and stop upon
reaching the value returned by CPU_COUNT(3) (rather than iterâ
ating over the number of bits requested to be allocated).
> This whole interface could have been designed much better (compare
> select to epoll, for instance).
Indeed!
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/