Date: Sat, 12 Jan 2008 18:34:06 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: arch@freebsd.org Subject: Re: Linux compatible setaffinity. Message-ID: <20080112182948.F36731@fledge.watson.org> In-Reply-To: <18311.49715.457070.397815@grasshopper.cs.duke.edu> References: <20071219211025.T899@desktop> <18311.49715.457070.397815@grasshopper.cs.duke.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 11 Jan 2008, Andrew Gallatin wrote: > I'm somewhat surprised that this has not hit the tree yet. What happened? > Wasn't the consensus that it was a good thing? I think Jeff just got busy with other stuff. > FWIW, I was too busy to reply at the time, but I agree that the Apple > interface is nice. However, sometimes one needs a hard CPU binding > interface like this one, and I don't see any reason to defer adding this > interface in favor of the Apple one, since they are somewhat orthogonal. > I'd be strongly in favor of having a hard CPU binding interface. The Apple API is nice in terms of capabilities, but we wouldn't be able to use it directly as it Mach-esque (as I understand it). Of course, Jeff's implementation of the Linux API doesn't actually fully implement the API (it doesn't support constraining the CPU set vs. binding to one CPU, and the patch as-provided didn't support querying the binding). I agree I'd like to see if in the tree, if only because it would let me eliminate local hacks I have that do the same thing, but we should think about other interfaces that are more expressive in the longer term. For example, one thing I like about the Apple interface is the ability to specify general strategies for affinity rather than specific affinities -- "these threads like to be together, but they don't mind where that is". Likewise, the Solaris facility to be able to change a CPU set and have all the things pinned to it follow the centrally-administered set is a nice match for our concept of Jail. Finally, if we do want it to work well with Jail, and we want Jails to be able to be pinned to sets of CPUs, we also need a nested concept of how to handle affinity, in the event that the set of CPUs a Jail is running on changes, in which case perhaps you want relative numbering within the jail, or some other similar notion. Sounds like a nice whiteboard session at the BSDCan developer summit... Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080112182948.F36731>