Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] [hwloc-svn] svn:hwloc r1333
From: Brice Goglin (Brice.Goglin_at_[hidden])
Date: 2009-11-11 18:31:48

Samuel Thibault wrote:
> bgoglin_at_[hidden], le Wed 11 Nov 2009 11:33:31 -0500, a écrit :
>> +/** \brief Bind thread given by \p pid to CPU set \p cpuset.
>> + *
>> + * \note This function now manipulates hwloc cpusets.
>> + */
>> +static __inline int
>> +hwloc_plpa_sched_setaffinity(hwloc_topology_t topology, hwloc_pid_t pid, hwloc_cpuset_t cpuset)
>> +{
>> + /* FIXME: should be set_thread_cpubind with a pid */
>> + return hwloc_set_proc_cpubind(topology, pid, cpuset, 0);
>> +}
> That's one instance where the Linux interface is odd (it talks about a
> pid, but it's actually a thread, and there is no way to set the affinity
> mask of a whole process...) and I believe we shouldn't try to support
> all the cases. I'd suggest to bind a thread only when pid is 0. If
> pid is not zero, that means that either the application is calling the
> linux-only gettid() or some other linux-only way to get the tid of a
> specific thread, or it assumes that the target is a single-threaded
> process and thus providing the pid of that process is enough to change
> its cpu affinity. In that case we can use hwloc_set_proc_cpubind like
> already done above. Same for getaffinity.

The problem is that our hwloc/Linux does not implement
set_proc_cpubind() so far. That's why PLPA/hwloc reports that binding is
not supported.

What about we add set_proc_cpubind() support to Linux and:
* document in hwloc.h that it may bind a single thread if the
application (wrongly) passes a tid
* document that hwloc_plpa_sched_setaffinity now works on processes
instead of pids and that application should use thread_t and
set_thread_cpubind for local threads
* maybe return -ENOSYS on Linux if STRICT is given?