2.5: task cpu affinity syscalls

Linus,

Attached is a resync to 2.5.8-pre2 of my CPU affinity syscalls for 2.5's scheduler.

This patch implements two new syscalls:

int sched_setaffinity(pid_t pid, unsigned int len,
unsigned long *new_mask_ptr)

int sched_getaffinity(pid_t pid, unsigned int *user_len_ptr,
unsigned long *user_mask_ptr)

which set and get a task's CPU affinity, respectively. I think we do indeed need to export an interface for setting affinity for specific needs, but a simple exported bitmask representation of cpus_allowed is more than enough and these calls fit into our existing sched_* family.

These syscalls provide forward-compatibility with cpus_allowed changes, implement security, and use Ingo's existing set_cpus_allowed method.

These syscalls are based on code of Ingo's for 2.4.

Changes since last post:

- drop tasklist_lock before calling set_cpus_allowed. Holding it across the call may not be safe. Instead, pin the specific task_struct with get_task_struct.
- remove ifdef in code
- minor cleanups, resync, et cetera

Well-tested on both UP and SMP. A test program and a tool for setting affinity of processes is available at
ftp://ftp.kernel.org/pub/linux/kernel/people/rml/cpu-affinity
and your favorite mirror. Please apply.

Robert Love

diff -urN linux-2.5.8-pre2/arch/i386/kernel/entry.S linux/arch/i386/kernel/entry.S
@@ -717,6 +717,8 @@
 	.long SYMBOL_NAME(sys_tkill)
 	.long SYMBOL_NAME(sys_sendfile64)
 	.long SYMBOL_NAME(sys_futex)		/* 240 */
+	.long SYMBOL_NAME(sys_sched_setaffinity)
+	.long SYMBOL_NAME(sys_sched_getaffinity)
 
 	.rept NR_syscalls-(.-sys_call_table)/4
 		.long SYMBOL_NAME(sys_ni_syscall)

diff -urN linux-2.5.8-pre2/include/asm-i386/unistd.h linux/include/asm-i386/unistd.h
@@ -245,6 +245,8 @@
 #define __NR_tkill		238
 #define __NR_sendfile64		239
 #define __NR_futex		240
+#define __NR_sched_setaffinity	241
+#define __NR_sched_getaffinity	242
 
 /* user-visible error numbers are in the range -1 - -124: see <asm-i386/errno.h> */
 

Since this isnt 32/64 bit compatible on big endian machines, can you write some wrapper functions before all the archs implement it themselves?

Think of 32 bit userspace passing a big endian bitmask into a 64 bit kernel:

32 bit:
31-0 63-32 95-64 127-96

64 bit:
63-0 127-64

Anton