Date: Wed, 27 Oct 2010 06:06:06 -0700 From: Garrett Cooper <gcooper@FreeBSD.org> To: David Xu <davidxu@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: svn commit: r214409 - head/sys/kern Message-ID: <AANLkTi=Yc-3NJGgp69f3oYz4eA_6yJJWOJdRdwiDhupy@mail.gmail.com> 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 Wed, Oct 27, 2010 at 5:56 AM, David Xu <davidxu@freebsd.org> wrote: > Robert Watson wrote: >> >> On Wed, 27 Oct 2010, David Xu wrote: >> >>>>> I really hate to see such a problem that userland can not figure out >>>>> what kernel is using, I try hardly to guess, but still can not find what it >>>>> is using. yes, I think the doc may need to be fixed or another syscall is >>>>> needed. >>>> >>>> Well... Jeff's code in cpuset(1) does some trivial sizeof(mask) 's, >>>> but it just passes in cpuset_t for mask. I've seen different calling >>>> conventions at the kernel level when I tried to get my brain in sync with >>>> that for a bug I was looking at a few weeks ago (and sadly, failed to some >>>> degree). >>>> These syscalls are a bit confusing though, and apart from cpuset(1) >>>> there aren't any really good examples in the sourcebase on how to use them >>>> (at least not the last time I checked)... Thanks, -Garrett >>>> >>> The problem is that the size of cpuset is not fixed, it is tunable by the >>> recompiling kernel with different parameter, so if you have a program which >>> you want to adapt it to use any size of cpuset, it should be able to get the >>> size the kernel is using, if you don't have source code of the program, you >>> can not compile it with new parameter, then there is trouble. >> >> 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). >> >> Robert >> > 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 brought this up a while back over the Austin Group list, but it looks like I need to file an Aardvark ticket for it and attend the meetings so the OpenGroup folks actually take the issue to heart.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=Yc-3NJGgp69f3oYz4eA_6yJJWOJdRdwiDhupy>