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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27 Oct 2010, at 13:56, David Xu wrote: >> Yay, it's fd_set all over again :-). >>=20 >> It sounds like we might just need to add a sysctl and a few wrapper = functions in userspace along the lines of (hand-wave): >>=20 >> cpuset_t *cpuset_alloc(); >> void cpuset_free(); >>=20 >> 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. :-) >=20 > 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. Robert=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?0D9C8E2A-520C-4A45-A93F-C958DDA421C6>