Samuel Thibault wrote:
> bgog...@osl.iu.edu, 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?
Brice
