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 /usr/include/bits/sched.h: #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: SYNOPSIS #include <sched.h> int sched_setaffinity(pid_t pid, unsigned int len, unsigned long *mask); int sched_getaffinity(pid_t pid, unsigned int len, unsigned long *mask); 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)) { perror("error!\n"); exit(1); } 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.
Man pages aren't part of glibc. info libc 'CPU Affinity' describes the current API.
*** This bug has been marked as a duplicate of 195031 ***