Re: [Xen-devel] [PATCH 1 of 4 v6/leftover] libxl: enable automatic placement of guests on NUMA nodes

[Dario Faggioli <raistlin@xxxxxxxx>]

On Mon, 2012-07-23 at 16:50 +0100, Ian Jackson wrote:
> Dario Faggioli writes ("Re: [PATCH 1 of 4 v6/leftover] libxl: enable 
> automatic placement of guests on NUMA nodes"):
> > On Mon, 2012-07-23 at 12:38 +0100, Ian Jackson wrote:
> > > This probably deserves a log message.
> > 
> > It's there: it's being printed by libxl__get_numa_candidate(). It's like
> > that to avoid printing more of them, which would be confusing, e.g.,
> > something like this:
> > 
> >  libxl: ERROR Too many nodes
> >  libxl: ERROR No placement found
> > 
> > Is that acceptable?
> 
> Two messages is better than one vague one.  
>
I agree, but in this specific case, it looked particularly ugly, as we
were telling the user that we decided not to run placement _and_ also
that he should be worried because placement did not succeeded! :-O

> One message would be
> better but then you have to make sure of course that every path
> prints exactly one message.
>
What I want is no path producing two (or more) conflicting indications. 

Basically, putting the message saying that we haven't found any
placement in the function that actually looks for the placement
--instead than in its callers-- I ensure that either an error happens
(and it's logged) before the placement itself could take place, or it
manages in running, does not find anything a log that... And this all
looks reasonable to me.

Also, I tested the various path (by creating fake nodes, etc.), and it
seems to behave as you ask. I'll double check that, if it turns out to
be that way, are you fine with it?

> > Well, it is for me, but as we agreed on 8, I went for that. What I
> > wanted was just make sure we (or whoever else) know/remember that 16
> > cold work too, in case that turns out to be useful in future. That being
> > said, if you agree on raising the cap to 16 right now, I'll be glad to
> > do that. :-D
> 
> I don't have a particular opinion on exactly what the cap should be.
> It should be sufficiently tight to prevent runaways.  A 2^16 worst
> case computation on domain start is certainly arguably acceptable.
> 
Ok, I'll go for 16 then (and will fix the 65536-->65535).

Thanks and Regards,
Dario

-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://retis.sssup.it/people/faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel