A follow up question, can the call to hwloc_get_non_io_ancestor_obj() return a
> On Mar 14, 2018, at 3:09 PM, Madhu, Kavitha Tiptur wrote:
> This function was used to query depth of hardware objects of a certain type
> to bind processes to objects at the
Good point. In theory, that's possible because we only look at cpusets
(NUMA nodes have cpusets, I/O don't). So the name of the function still
matches its behavior.
However it won't happen in practice with the current code because I/O
are always attached to CPU objects. But it may change in the
Thanks for the response.
> On Mar 14, 2018, at 4:28 PM, Brice Goglin wrote:
> Good point. In theory, that's possible because we only look at cpusets
> (NUMA nodes have cpusets, I/O don't). So the name of the function still
> matches its behavior.
> However it won't
I can fix the documentation to say that the function always suceeds and
returns the virtual depth for NUMA/IO/Misc.
I don't understand your third sentence. If by "actual depth", you mean
the depth of a (normal) parent where NUMA are attached (for instance the
depth of Package if NUMAs are
The function hwloc_get_type_or_above_depth() is supposed to return the depth of
objects of type “type" or above. It internally calls hwloc_get_type_depth which
returns virtual depths to NUMA, IO and misc objects. In order to retrieve the
actual depth of these objects, one needs to
This function was used to query depth of hardware objects of a certain type to
bind processes to objects at the depth or above in Hydra previously. As you
pointed out, the functionality makes no sense with NUMA/IO objects possibly
being at different depths or for objects.
> On Mar 14, 2018,