Date: Wed, 27 Oct 2010 14:12:03 +0100 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: David Xu <davidxu@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Garrett Cooper <gcooper@freebsd.org> Subject: Re: svn commit: r214409 - head/sys/kern Message-ID: <0D9C8E2A-520C-4A45-A93F-C958DDA421C6@FreeBSD.org> In-Reply-To: <4CC82195.5000201@freebsd.org> References: <201010270232.o9R2Wsu3084553@svn.freebsd.org> <AANLkTi=2dTVmB8Goj%2BNXq4F6SmZBNS3bxn8gLjmQ%2BdfV@mail.gmail.com> <4CC803A8.3040602@freebsd.org> <AANLkTimddEnxCLNWd%2BtWVANXCzu8ZkNHQumXCU8a_8yT@mail.gmail.com> <4CC80ABA.3080404@freebsd.org> <alpine.BSF.2.00.1010271216160.32645@fledge.watson.org> <4CC82195.5000201@freebsd.org>
index | next in thread | previous in thread | raw e-mail
On 27 Oct 2010, at 13:56, David Xu wrote: >> Yay, it's fd_set all over again :-). >> >> It sounds like we might just need to add a sysctl and a few wrapper functions in userspace along the lines of (hand-wave): >> >> cpuset_t *cpuset_alloc(); >> void cpuset_free(); >> >> And perhaps some sort of API that abstracts manipulation of the set (or >> doesn't but allows the user to easily query its bounds). > Problem is who will use the non-standard interface ? The pthread_attr_getaffinity_np pthread_attr_setaffinity_np > and others are from glibc, which let you specify arbitrary > cpuset size but kernel only accept one size. :-) > > Though it is not POSIX, but some software start to use it, AFAIK, > Erlang language's VM start to use it for binding its scheduler > thread to cpu, we have to live with it. We still lack of some functions > to let it compile without modification, one is it wants to know > cpu topology, and other crappy functions it wants to use is: > sched_getaffinity, sched_setaffinity, which one guy thought each > thread is just a process which has a PID. :-) > I don't know how it uses Solaris processor binding interface. I see two separate problems here: (1) Providing potentially non-portable APIs that do the right thing, and do it well. (2) Providing definitely portable APIs whose implementation is as robust as possible given their flawed semantics. I.e., don't crash on common use. The latter should be implemented in terms of the former. Roberthelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0D9C8E2A-520C-4A45-A93F-C958DDA421C6>