Linux compatible setaffinity.

Julian Elischer julian at elischer.org
Thu Dec 20 10:18:57 PST 2007


Jeff Roberson wrote:
> 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.


makes sense to me..
don't forget the man page!

> 
> Thanks,
> Jeff
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> freebsd-arch at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"



More information about the freebsd-arch mailing list