Linux compatible setaffinity.

[Andre Oppermann]

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.

The Linux (and Solaris) style setaffinity is rather low level and
any user of it has to make many assumptions based on incomplete
knowledge of the underlying hardware and its architecture (buses,
caches, latency between cores, etc).

In practical use I'd rather have a function to bind myself to the
current CPU or CPU number X, and then to specify that new threads
or forked processes should emerge on another, but not this CPU.
Pepper that with a few hints like latency and cache affinity (important
or not important) the kernel can act on appropriately and it becomes
much more powerful and simpler to use.  Taking it even further an
application may want to specify that it would like to run on a number
X of cores that are close (latency/cache) together, be permanently
bound to it and to repel any other such requests.  This way I can
run my database server on socket 1 cores 1-4, and the webserver on
socket 2 cores 5-8 more or less automagically.  sched_setaffinity
requires a lot of operator involvement and architecture knowledge
to make that happen.

Not that I'm against a Linux compatible sched_setaffinity(), it's
just not as practical to use as other constructs.

Food for thought.

-- 
Andre