Linux compatible setaffinity.
jroberson at chesapeake.net
Wed Feb 20 22:32:27 UTC 2008
On Wed, 20 Feb 2008, Daniel Eischen wrote:
> On Tue, 19 Feb 2008, Jeff Roberson wrote:
>> On Sat, 12 Jan 2008, Jeff Roberson wrote:
>>> On Sat, 12 Jan 2008, Daniel Eischen wrote:
>>>> On Sat, 12 Jan 2008, Jeff Roberson wrote:
>>>>> Now, there is one problem with the linux api that I want to discuss
>>>>> before I commit it. The current patch always works on curthread.
>>>>> However, the api allows for setting the binding of a pid. I believe,
>>>>> although I'm not certain, that pids and tids in linux are in the same
>>>>> number space. It's not clear to me whether you can set an affinity for
>>>>> an entire process and have it effect an individual thread or whether you
>>>>> set it on a thread by thread basis. When supplying a non-curproc pid do
>>>>> you bind all threads in the target process?
>>>>> Are our tids and pids in the same number space? And are they available
>>>>> to application programmers? I haven't followed that very carefully.
>>>> I believe marcel made tids and pids disjoint so that any pid is
>>>> never equal to any tid. But regardless, I don't think we want
>>>> to rely on that. I would prefer the Solaris approach of specifying
>>>> what we want (pid, tid, jail id, etc) as an argument in the API
>>>> so there is no confusion.
>>> Yes, I would prefer that as well I believe. So I'll add an extra
>>> parameter and in the linux code we'll use whatever their default is. Of
>>> course the initial implementation will still only support curthread but I
>>> plan on finishing the rest before 8.0 is done.
>> So what does everyone think of something like this:
>> int cpuaffinity(int cmd, long which, int masksize, unsigned *mask);
>> #define AFFINITY_GET 0x1
>> #define AFFINITY_SET 0x2
>> #define AFFINITY_PID 0x4
>> #define AFFINITY_TID 0x8
>> I'm not married to any of these names. If you know of something that would
>> be more regular please comment.
> I take it 'cmd' is either AFFINITY_GET or AFFINITY_SET, and which
> is AFFINITY_PID or AFFINITY_TID. Is there a reason why, for 2 different
> arguments to cpuaffinity(), the flags are disjoint? It almost seems
> like you wanted:
> int cpuaffinity(int flags, int masksize, unsigned *mask)
> I prefer the API you specified, keeping 'cmd' and 'which' as
> separate arguments.
Yes, I'll either do that or have seperate get/set syscalls.
> Is masksize in bytes or in units of unsigned? Do we need helper
> functions/macros for the mask? Like sigemptyset, sigaddset, etc?
I have macros copied from FD_SET, as CPU_SET, CPU_ISSET, etc.
This will go in sys/sched.h.
More information about the freebsd-arch