Date: Wed, 27 Oct 2010 20:56:53 +0800 From: David Xu <davidxu@freebsd.org> To: Robert 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: <4CC82195.5000201@freebsd.org> In-Reply-To: <alpine.BSF.2.00.1010271216160.32645@fledge.watson.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4CC82195.5000201>