That doesn't really work with the hwloc model unfortunately. Also, when you get to smaller objects (cores, threads, ...) there are multiple "closest" objects at each depth.

We have one "closest" object at some depth (usually Machine or NUMA node). If you need something higher, you just walk the parent links. If you need something smaller, you look at children.

Also, each I/O device isn't directly attached to such a closest object. It's usually attached under some bridge objects. There's a tree of hwloc PCI bus objects exactly like you have a tree of hwloc sockets/cores/threads/etc. At the top of the I/O tree, one (bridge) object is attached to a regular object as explained earlier. So, when you have a random hwloc PCI object, you get its locality by walking up its parent link until you find a non-I/O object (one whose cpuset isn't NULL). hwloc/helper.h gives you hwloc_get_non_io_ancestor_obj() to do that.


Le 09/02/2012 14:34, Ralph Castain a écrit :
Ah, okay - in that case, having the I/O device attached to the "closest" object at each depth would be ideal from an OMPI perspective.

On Feb 9, 2012, at 6:30 AM, Brice Goglin wrote:

The bios usually tells you which numa location is close to each host-to-pci bridge. So the answer is yes.

Ralph Castain <> a écrit :
I'm not sure I understand this comment. A PCI device is attached to the node, not to any specific location within the node, isn't it? Can you really say that a PCI device is "attached" to a specific NUMA location, for example?

On Feb 9, 2012, at 6:15 AM, Jeff Squyres wrote:

That doesn't seem too attractive from an OMPI perspective, though.  We'd want to know where the PCI devices are actually rooted.

devel mailing list

_______________________________________________ devel mailing list