Samuel Thibault wrote:
> Now, coming to semantic changes:
> - The top node of the tree wouldn't necessarily be a system object.
>   Actually, having always the top object having the system type is not
>   providing any useful information :)

And having the root object type vary from machine to system or switch
provides useful information about what kind of topology we're working on.

> - Objects of network trees may not have cpusets defined  (Trees obtained
>   directly from hwloc with defaults parameter would still have cpusets
>   on every node however).  It does not make sense to merge cpusets of
>   different machines (they will conflict), and things like shifting
>   cpusets to be able to merge them would probably only bring issues.
>   That being said, that does not prevent from writing a transparency
>   plugin that automatically discovers the network topology, shifts
>   cpusets, and when requested for binding, automatically migrates to
>   the machine according to the shift, and uses the underlying OS hooks
>   to perform the binding.  My point is that the hwloc combining operation
>   wouldn't fix cpusets itself and leave them NULL. The caller of the
>   combining operation will be responsible for that.
>   

By the way, I thought about making cpuset NULL in PCI objects. But it
wasn't strictly required there so I just kept using empty cpusets
instead of changing everything else to support NULL.

Brice

Reply via email to