Re: [Xen-devel] [PATCH 11 of 11] Some automatic NUMA placement documentation

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Dario Faggioli writes ("Re: [Xen-devel] [PATCH 11 of 11] Some automatic NUMA 
placement documentation"):
> On Thu, 2012-05-31 at 16:08 +0100, Ian Jackson wrote:
> > In general I would prefer to see docs come in the same patch but I
> > guess I can read it here:
> 
> I can put it there. Would you recommend _moving_ it in the source file o
> also leaving a copy, o maybe just some pointers, here?

In general I don't mind whether API docs are in a separate file or in
the source headers.  What we have here is sufficiently complex that it
seems to merit its own file.  A reference to it from libxl.h would be
appropriate.

> Right, that is of couse an option, and I thought about going that way
> for quite a while. However, what I think is best for libxl is to provide
> a set of building blocks for its user to be able to implement the actual
> heuristics.

The difficulty with this is that this is supposedly becoming a stable
API.  If we change the approach later, we may want to change the API.
Do we know clearly enough what building blocks are needed and what
they should be like ?

I think it would be easier, at this stage for 4.2, simply to offer a
single `do something sensible' heuristic, and then think about more
complicated control by the caller for 4.3.

> Doing it the other way, i.e., one big function doing everything, would
> mean that as soon as we want to change or improve the placement
> heuristics, we need to modify the behaviour of that API call, which I
> think it is suboptimal.

If we have a function whose documented behaviour is `try to do a
roughly optimal thing' then improving its optimisation is not a change
to the API semantics.

Specifically, existing code then will, when upgraded to a newer libxl,
behaviour differently - better, we hope.  Is that not the intent ?

>   Also, if some other user of libxl does not like
> the heuristics I came out with, they have to reimplement the whole
> placement.

I think users of 4.2 won't be doing that.  That is, we can tell them
to please wait for 4.3 when we will have a richer API for this kind of
thing.

> So, like it is right now, the actual heuristics is implemented in xl, on
> top of these placement candidate generation and manipulation facilities,
> which I finally decided it was the way I liked this whole thing
> most. :-)

So how much of the code currently in libxl should be reproduced in
(say) libvirt ?

> Again, you're right in asking this reasoning to be part of the
> documentation, and to be put in the proper place, and I will do that.
> However, now that I've put it here, do you think it makes some sense?

I think it's fine for it to be in a separate file.  But I think it
should ideally be in the same patch as the implementation.

> > > +        libxl_numa_candidate_count_domains(libxl_ctx *ctx,
> > > +                                           libxl_numa_candidate 
> > > *candidate);
> > > +
> > > +This is what counts the number of domains that are currently pinned
> > > +to the CPUs of the nodes of a given candidate.
> > 
> > Why is that useful ?  It is used by some of your other code so I guess
> > this is a facility which is useful to the implementors of other
> > placement algorithms ?
> 
> As I tried to explain above, yes, exactly like that.

Are we really sure that we want to support this API for a long time ?

Ian.

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