Date: Sat, 22 Dec 2007 20:36:32 -1000 (HST) From: Jeff Roberson <jroberson@chesapeake.net> To: David Xu <davidxu@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: Linux compatible setaffinity. Message-ID: <20071222203443.U899@desktop> In-Reply-To: <476B1973.6070902@freebsd.org> References: <20071219211025.T899@desktop> <476B1973.6070902@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071222203443.U899>