Linux compatible setaffinity.
Jeff Roberson
jroberson at chesapeake.net
Sat Dec 22 22:35:16 PST 2007
On Fri, 21 Dec 2007, David Xu wrote:
> 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.
>>
>> Thanks,
>> Jeff
>>
>
> I don't say no to these interfaces, but there is a need to tell
> user which cpus are sharing cache, or memory distance is closest enough,
> and which cpus are servicing interrupts, e.g, network interrupt and
> disks etc, etc, otherwise, blindly setting cpu affinity mask only
> can shoot itself in the foot.
I don't disagree with you, however, I think in most cases the affinity
mask is used for very special purpose applications. In the cases I have
observed, anyhow, the application is tailored to the particular machine.
So hopefully the programmer knows these things. I would prefer that it
not crop up as a general interface that normal applcations use to try to
improve performance. We should hope that we can improve the schedulers to
do these things automatically.
Thanks,
Jeff
>
> Regards,
> David Xu
>
More information about the freebsd-arch
mailing list