Bug 173945 - sched_setaffinity manpage is inacurate
sched_setaffinity manpage is inacurate
Status: CLOSED DUPLICATE of bug 195031
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: man-pages (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ivana Varekova
Ben Levenson
Depends On: 168429
  Show dependency treegraph
Reported: 2005-11-22 16:00 EST by Tim Burke
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-06-15 03:55:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tim Burke 2005-11-22 16:00:52 EST
In RHEL4U3, we are increasing in the kernel, the number of supported CPUs to be
above 64 for PPC and Itanium.  In the course of investigating the side-effects,
Ingo pointed out that the manpage for sched_[set|get]affinity is quite
disorganized.  Here's an excerpt from his mail:

current glibc APIs properly support up to 1024 CPUs, see

 #if defined _SCHED_H && !defined __cpu_set_t_defined
 # define __cpu_set_t_defined
 /* Size definition for CPU sets.  */
 # define __CPU_SETSIZE  1024
 # define __NCPUBITS     (8 * sizeof (__cpu_mask))

so the problem is not technical but more psychological. If you type:
   man sched_setaffinity

on a FC4 box, the manpage starts with:

       #include <sched.h>

       int  sched_setaffinity(pid_t  pid,  unsigned  int  len,  unsigned  long

       int  sched_getaffinity(pid_t  pid,  unsigned  int  len,  unsigned  long

which is the old 'wrong' API that limits things to 64 CPUs. Only further 
down, in the 'HISTORY' section is the real API described:

       /* Set the CPU affinity for a task */
       extern int sched_setaffinity (pid_t pid, size_t cpusetsize,
                                     const cpu_set_t *cpuset);

       /* Get the CPU affinity for a task */
       extern int sched_getaffinity (pid_t pid, size_t cpusetsize,
                                     cpu_set_t *cpuset);

i'd not be surprised if there were a number of applications that still 
used the following type of code:

 #define __USE_GNU
 #include <sched.h>

 int main (void)
         int cpu = 10;
         unsigned long mask = 1 << cpu;

         // bind to CPU#10:
         if (sched_setaffinity(0, sizeof(mask), &mask)) {

         return 0;

the above code, if compiled with -Wall, will give this warning:

 warning: passing argument 3 of 'sched_setaffinity' from incompatible pointer type

but the code will otherwise link and run fine, and will handle cpu values
0-63. How widespread this problem is - i dont know, maybe the glibc folks 
have some estimation.
Comment 1 Jakub Jelinek 2005-11-22 16:10:30 EST
Man pages aren't part of glibc.  info libc 'CPU Affinity' describes the current
Comment 2 Ivana Varekova 2006-06-15 03:55:04 EDT

*** This bug has been marked as a duplicate of 195031 ***

Note You need to log in before you can comment on or make changes to this bug.