On 26/12/2013 22:52, Brice Goglin wrote:
> How would you like the user to switch from the fake/guest topology to
> the real/host topology in practice? Most applications may still want
> fake/guest topos (so that binding works etc) while admins and only some
> (advanced?) users will want the real/host topology.
> We can easily make Xen lower priority by default and use environment
> variables to raise/enable Xen manually. But I am not sure that's a
> convenient solution for the end user.
> If we add --enable-xen, you'd want to have two hwloc installations, a
> normal one and a xen-enabled one?
I was hoping to put off that question.
There is an interesting development in progress at the moment to give a
VM some real topology information, based on where its vcpus are actually
pinned. At the moment by default, a vcpu is eligible to be scheduled on
any pcpu, and the memory is deliberately striped across all numa nodes
so the performance is equally wherever the vcpu is scheduled.
This was fine 10 years ago, but is a large performance penalty these
days, which is why there is a lot of work going on to rectify the
situation. As a result, I can foresee a proper usecase for the hwloc
binding using the VM-presented topology.
In hindsight, an --enable-xen option is probably silly, as I
(personally) would specifically not want two builds of hwloc in dom0.
Having said that, having a low priority and some environmental tweak is
At the end of the day, the system level topology is almost certainly
going to be a read-only source of information. Therefore, it make most
sense for a host administrator to go out of their way when looking at
the system topology, rather than attempting to tune things inside the
dom0 fake topology.