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
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
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
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,
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