On Fri, Jan 23, 2009 at 23:10, Fawzi Mohamed <fawzi_at_[hidden]> wrote:
>
> On Jan 23, 2009, at 7:33 PM, Bert Wesarg wrote:
>
>> On Fri, Jan 23, 2009 at 19:22, Fawzi Mohamed <fawzi_at_[hidden]> wrote:
>>>
>>> I was wondering if there was any plan to support the setting/getting of
>>> the
>>> affinity of threads.
>>>
>>> I tried to understand a little the situation:
>>>
>>> Using LinuxThreads one has a pid for each thread, so one can use the
>>> sched_setaffinity after getting the bit with gettid.
>>>
>>> Using NPTL starting with libgc 2.3.4 one can use
>>> pthread_[attr_]_[get|set]affinity_np (defining _GNU_SOURCE)
>>> This is very nice, but not always available.
>>>
>>> Looking at the documentation in one place it is said that using
>>> sched_setaffinity(0,...) one sets only the current thread. Is this so
>>> everywhere? If so I could use that in my code.
>>
>> Whats 'everywhere'?
>
> in all system where plpa set/get affinity works.
>
>>> Is there a plan to directly support thread affinity (vs process)?
>>
>> You can use PLPA with NPTL, just use the tid (from gettid(2)) as the
>> pid.
>
> ok thanks I was not sure that that would work with NPTL, because the
> documentation was very unclear about it.
> I thought that as NPTL did not use pids, so that one could not use that
> (because of collisions between process ids and thread pids...
> So that gettid would return different pids only for thread groups, i.e.
> threads created with clone, and not those created with NPTL...
> I have to test it then.
>
>> The only problem left is the mapping from pthread_t to tid (so
>> you could set the affinity for one thread from another thread (of the
>> same process of course)). This is the only advantage of the
>> pthread_[get|set]affinity_np interface. To simulate the
>> pthread_attr__[get|set]affinity_np interface, the calling thread could
>> set his mask to the desired one, create the thread, and set the mask
>> back. This should work because the affinity mask will be inherited.
>
> thank you for the answers.
>
> does this mean that there is no idea of supporting threads better? well the
> fact that it works at least for the executing thread is already nice.
Can I remember you why this project was created in the first place: it
was created because the API of the sched_{set,get}affinity() functions
have changed twice. To overcome this portability problem, this
wrapper library was created to support any of the known incarnations
of this API.
AFAIK, the pthread API has never changed. So your are probably safe to
use this API directly.
Now you have probably a problem if you want to pass a mask get from a
PLPA function (i.e. of type plpa_cpu_set_t) to the pthread functions
(i.e. cpu_set_t): thankfully this is not a problem, you should simply
cast plpa_cpu_set_t* to a cpu_set_t*.
The real problem is the mapping from pthread_t to tid, that prevents
us from incorporating this into PLPA. The mapping (actually just a
member of the internal pthread_t struct) is a internal property of the
nptl/glibc, which we should avoid to touch.
The only thing we could give is a convenient way to 'convert' from
plpa_cpu_set_t to cpu_set_t and back, to help the interaction with
other interfaces of the affinity mask.
Bert
>
> Fawzi
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}