Date: Thu, 20 Dec 2007 12:11:08 +0100 From: Andre Oppermann <andre@freebsd.org> To: Jeff Roberson <jroberson@chesapeake.net> Cc: arch@freebsd.org Subject: Re: Linux compatible setaffinity. Message-ID: <476A4DCC.4040206@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. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?476A4DCC.4040206>