Linux compatible setaffinity.

[Jeff Roberson]

I have implemented a linux compatible sched_setaffinity() call which is 
somewhat crippled.  This allows a userspace process to supply a bitmask of 
processors which it will run on.  I have copied the linux interface such 
that it should be api compatible because I believe it is a sensible 
interface and they beat us to it by 3 years.

My implementation is crippled in that it supports binding by curthread 
only and to a single cpu only.  Neither of the schedulers presently 
support binding to multiple cpus or binding a non-curthread thread.  This 
property is not inherited by forked threads and does not effect other 
threads in the same process.  These two limitations can gradually be 
weakened without effecting the syscall api.

The linux api is:
int    sched_setaffinity(pid_t pid, unsigned int cpusetsize, cpu_set_t 
*mask);

The cpu_set_t is the same as a fdset for select.  The cpusetsize argument 
is used to determine the size of the array in mask.

I'm mostly interested in feedback on how best to reduce the namespace 
pollution and avoid pulling the sched.h file into the generated syscall 
files (sysproto.h, etc).  Anyone who feels this is a terrible interface 
for such a thing should speak up now.

I also feel that in the medium term we will have to deal with machines 
with more cores than bits in their native word.  Using these CPU_SET, 
CPU_CLR macros is a fine way to deal with this issue.

I also have a primitive 'taskset', although I don't like the name, it 
allows you to run arbitrary programs bound to a single cpu.

Thanks,
Jeff
-------------- next part --------------
A non-text attachment was scrubbed...
Name: setaffinity.diff
Type: text/x-diff
Size: 5129 bytes
Desc: 
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20071220/26bedb88/setaffinity.bin