Date: Wed, 27 Oct 2010 23:19:06 +0800 From: David Xu <davidxu@freebsd.org> To: "Robert N. M. Watson" <rwatson@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: <4CC842EA.7030308@freebsd.org> In-Reply-To: <0D9C8E2A-520C-4A45-A93F-C958DDA421C6@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> <0D9C8E2A-520C-4A45-A93F-C958DDA421C6@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Robert N. M. Watson wrote: > 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. > > Robert > You still can make wrapper functions, the glibc pthread API is unrelated to this. you can write a library to manage the cpuset, cpuset allocation and freeing are done by the library, but hide or make the cpuset size read-only, the size can be queried but can not be changed, the cpuset when allocated always has same size as kernel's. you even can do more work, explore kernel cpu topology data and provide interface, current one can only access xml data via sysctl kern.sched.topology_spec which is not easy if a program can not parse xml, even there is a parser, it is still not easy.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CC842EA.7030308>