Re: [libvirt] [PATCH v3 1/3] libxl: implement NUMA capabilities reporting
On mar, 2013-07-16 at 11:18 +0100, Daniel P. Berrange wrote:
On Tue, Jul 16, 2013 at 11:10:25AM +0100, Dario Faggioli wrote:
> There are indeed a couple of possible reasons. Actually, I saw that the
> qemu driver does pretty much the same, i.e., if retrieving NUMA
> information fails, it gives up on that, but does not make things
> explode, and I really think it is something that makes sense.
The reason the QEMU driver does that is that libnuma will return an
error if the host machine does not expose NUMA info in its BIOS. This
is an expected, valid scenario, so we have to ignore the error and
libnuma provides no way to distinguish this valid scenario from other
errors.
Ok, I see.
> The actual possible failure reasons are: (1) it cannot prepare
the
> parameters for the hypercall, or (2) the hypercall fails. It is true
> that, in both cases, something really serious might have happened, but
> there is no way to tell it from here. Thus, I honestly think that trying
> to carry on is sound... If it is really the case that some critical
> component died, we'll find out soon enough.
The only scenario in which it is acceptable to ignore the failure
is if the physical hardware does not support NUMA. The question is
whether the Xen API lets you distinguish that scenario, from other
types of errors.
Mmm... I see what you mean. Well, I guess it depends on what you mean by
'not support'. If we're talking about a box with only 1 NUMA node, and
call it a non-NUMA box, then libxl will just tell you that there is only
that 1 node, and that is already being taken care of properly (see Jim's
testing of the series).
If "host machine does not expose NUMA info in its BIOS" means something
different than that, then I've just never put hands on one of such
machine, hence I really am not sure what Xen would tell libxl about
them.
Anyway, it really looks to me too now that I should not special case
errors happening in libxl_get_numainfo(), and treat them as all the
other ones. I'll do that.
Thanks again and Regards,
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
Attachments:
- signature.asc (application/pgp-signature — 198 bytes)