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
jsquy...@cisco.com
