Date: Fri, 21 Dec 2007 09:40:03 +0800 From: David Xu <davidxu@FreeBSD.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: arch@FreeBSD.org Subject: Re: Linux compatible setaffinity. Message-ID: <476B1973.6070902@freebsd.org> In-Reply-To: <20071219211025.T899@desktop> References: <20071219211025.T899@desktop>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Regards, David Xu
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?476B1973.6070902>