On Wed, 2015-04-29 at 12:58 +0100, Daniel P. Berrange wrote:
> It seems to me that every application that uses libnuma is going to
> potentially suffer from the same problem. As such I don't think it
> is a good use of effort to workaround it in libvirt - it should be
> fixed in libnuma itself, so every applications benefits from the
> fix.
You're right, and in fact I had already filed a bug against numactl[1].
The reasoning behind removing numa_node_to_cpus() usage is as follows:
1. we have no idea whether libnuma's upstream is going to agree that
the caching behavior is problematic, or how long it's going to
take for the change to be implemented; even when that does happen,
it's not clear to me how we would deal with it - would that be a
new API version? Would we have to deal with both API versions?
Doing so would mean basically adding this code anyway, while not
doing so would mean depending on a fairly new release of libnuma;
2. detecting the host's topology should probably not be tied to the
availability of libnuma, which is an optional feature that can be
turned off at configure time, as all the information we need is
exposed by the kernel already;
3. most importantly, we're already parsing the information available
in sysfs ourself, because libnuma doesn't offer an API to retrieve
information about cores, threads etc. and as such is not enough to
build the full host topology.
Of course my reasoning might be completely off, so feel free to point
out any issue with it :)
Cheers.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1213835
--
Andrea Bolognani <abologna@xxxxxxxxxx>
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list