On Nov 9, 2009, at 5:12 AM, Samuel Thibault wrote:
> What I dislike in that approach is that it means we'd have to closely
> follow future changes in the kernel ABI, while the API is not supposed
> to change (even if it has in the past). Also, now that glibc provides
> pthread_setaffinity_np, we should take advantage of it to implement
> hwloc_set_thread_cpubind, and there is no way we can re-implement it
> ourselves (the missing piece is the pthread_t -> tid translation).
>
Fair enough. What about if we have an AC check for
pthread_setaffinity_np and use that if it exists, and if it doesn't
use the PLPA way? So if the timeline looks like this:
----- way in the past (time flows down)
|
-----> "bad" setaffinity days of kernel/glibc mixing
| PLPA method is known to work here
|
-----> pthread_setaffinity_np is introduced, fixes problems
|
\|/
----- present
Then if AC causes hwloc to prefer pthread_setaffinity_np(), then we're
covered for all the old systems with either old kernels and/or old
glibc where problems occur.
BTW, how does pthread_setaffinity_np() work? Does it check the
running kernel and ensure to do the Right Thing? That was definitely
a problem in the past -- kernel and glibc would mismatch in terms of
set/getaffinity (which was included in many distros).
--
Jeff Squyres
jsquyres_at_[hidden]
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}