Re: [hwloc-devel] towards PLPA-like API in 1.0
Brice Goglin wrote:
> * Probing
>
> >From what I understand, plpa_have_topology_information() tells whether
> PLPA knows what's in the hardware, while plpa_api_probe() tells whether
> binding is supported. We could add:
>
> + hwloc_topology_support(hwloc_topology_t topology, unsigned *support)
>
/** \brief Flags describing the actual OS support for this topology.
*
* Flags are retrieved with hwloc_topology_get_support().
*/
enum hwloc_topology_support_flags_e {
/* \brief Topology discovery is supported. */
HWLOC_SUPPORT_DISCOVERY = (1<<0),
/* \brief Binding a process is supported. */
HWLOC_SUPPORT_SET_PROC_CPUBIND = (1<<1),
/* \brief Binding a thread is supported. */
HWLOC_SUPPORT_SET_THREAD_CPUBIND = (1<<2),
/* \brief Getting the binding of a process is supported. */
HWLOC_SUPPORT_GET_PROC_CPUBIND = (1<<3),
/* \brief Getting the binding of a thread is supported. */
HWLOC_SUPPORT_GET_THREAD_CPUBIND = (1<<4),
};
/** \brief Retrieve the OR'ed flags of topology support. */
extern int hwloc_topology_get_support(hwloc_topology_t __hwloc_restrict
topology, unsigned long flags);
I don't think we need SET_CPUBIND since (from what I understand) it
would be equivalent to SET_PROC_CPUBIND | SET_THREAD_CPUBIND. We'd have
to keep in mind that 32bits in this flag bitmask is small (we'll likely
need many other flags in the future, for instance IODEVICE_DISCOVERY,
SET/GET_MEMBIND, SET/GET_RANGE_MEMBIND).
Brice
Re: [hwloc-devel] Pgcc issues fixed?
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
Re: [hwloc-devel] Pgcc issues fixed?
Jeff Squyres, le Thu 05 Nov 2009 07:58:58 -0500, a écrit : > This problem may go away if we adapt PLPA's approach to sched_[set| > get]affinity. 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). Samuel
