On Wed, Oct 27, 2010 at 5:56 AM, David Xu <davi...@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. _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
