svn commit: r214409 - head/sys/kern

David Xu davidxu at
Wed Oct 27 15:19:23 UTC 2010

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.

More information about the svn-src-head mailing list