Linux compatible setaffinity.
jroberson at chesapeake.net
Wed Dec 19 23:18:37 PST 2007
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
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 5129 bytes
Url : http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20071220/26bedb88/setaffinity.bin
More information about the freebsd-arch