Brice Goglin, le Mon 09 Nov 2009 15:18:11 +0100, a écrit :
> I don't think we need SET_CPUBIND since (from what I understand) it
> would be equivalent to SET_PROC_CPUBIND | SET_THREAD_CPUBIND.
Being able to set oneself's cpuset is not the same as being able to set
the cpuset of other processes or other threads.
We should also probably expose whether strict binding is available and
whether whole processes and single threads can be bound.
In a word, I believe we should just expose which exact parts of the
binding API will never return ENOSYS. That would make it a lot easier
to comprehend and much more straightforward to use it even though
the interface is very powerful and can thus lead to a lot of binding
possibilities. If an application has requirements A, B and C and would
be even happier if D and E were available, it can prepare arguments
for A, B and C, and if D and E are announced as being available, add
arguments for them, and then call the function. That saves trying with
D and E, or only with D, or only with E, and eventually fallback to not
> 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).
That's probably a hint that we should find another way :)
How about a function that returns a structure filled with one long
per feature (detection, thread bind, memory bind, etc.), part of
hwloc_topology_t? That way we can extend it at will.