Re: Linux compatible setaffinity.

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
_______________________________________________
freebsd-arch@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Intel memory latencies.
    ... Video encoding for instance is slow, cpu ... With 1 thread, max latency was 0.857 seconds, effective ... video compression of the result. ... So sure, most desktops don't need it, dual cores are the sweet spot ...
    (comp.arch)
  • Re: How to develop a random number generation device
    ... chip, and something new will be required to manage them. ... I think that the number of virtual cores will grow faster than the ... One CPU would be the manager, ... all about reliability. ...
    (sci.electronics.design)
  • Re: How to develop a random number generation device
    ... chip, and something new will be required to manage them. ... I think that the number of virtual cores will grow faster than the ... One CPU would be the manager, ... Multiple cores gives absolutely no benefits in terms of reliability or stability - indeed, it opens all sorts of possibilities for hard-to-debug race conditions. ...
    (sci.electronics.design)
  • Re: How to develop a random number generation device
    ... chip, and something new will be required to manage them. ... I think that the number of virtual cores will grow faster than the ... One CPU would be the manager, ... embedded systems - I know when reliability is important, ...
    (sci.electronics.design)
  • Re: How to develop a random number generation device
    ... I think that the number of virtual cores will grow faster than the ... My point/fantasy is that OS design should change radically if many, ... One CPU would be the manager, ... Multiple cores gives absolutely no benefits in terms of reliability or stability - indeed, it opens all sorts of possibilities for hard-to-debug race conditions. ...
    (sci.electronics.design)