svn commit: r214409 - head/sys/kern

[Garrett Cooper]

On Wed, Oct 27, 2010 at 5:56 AM, David Xu <davidxu at 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.