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)
Attachment:
signature.asc
Description: This is a digitally signed message part
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list