Re: [Xen-devel] [PATCH 08 of 10 v3] libxl: enable automatic placement of guests on NUMA nodes

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2012-07-06 at 15:40 +0100, George Dunlap wrote:
> On 06/07/12 15:35, Dario Faggioli wrote:
> > On Fri, 2012-07-06 at 14:05 +0100, George Dunlap wrote:
> >>> Ok, I get this like I can leave it as it is... Or you want me to kill
> >>> the sorting?
> >> I can't really foresee a time when anyone would want to use anything
> >> other than the best option.
> >>
> > Well, perhaps being able to do some more fiddling, like<<now that I
> > have all the ones that meet _THESE_ characteristics, and I have them in
> > _THAT_ precise ordering, let's pick up the first that meets _THIS_OTHER_
> > requirement>>.
> >
> > Anyway, it might well be over-thinking the whole thing. In my first RFC,
> > when I was introducing more placement policies (and the respective user
> > interfaces and configuration bits), I was exploiting the fact that, like
> > this, I never loose access to the full list of candidates, so, maybe
> > when/if that will be the case again (during 4.3 dev cycle) everything
> > will be more clear.
> >
> > As soon as we'll have a better picture of what feature and what
> > interface we want this whole placement thing to have, what kind of users
> > and behaviour we want to support (e.g., what libvirt does and what does
> > it require wrt NUMA placement), we could better decide what to do.
> > That's the benefit of having all this internally and not exported in any
> > means yet (a benefit for which I give you and Ian all the credits :-P).
> >
> >> Just choosing the best makes a slightly
> >> simpler interface, and simplified the code somewhat.
> >>
> > I can't and am not going to argue against that, as I think that too.
> >
> >> At the moment,
> >> sorting shouldn't take too long, but suppose we get systems with 128
> >> nodes at some point in the future -- then the number of possible
> >> combinations might be pretty large, and sorting that even at n log n
> >> might take a noticeable amount of time.
> >>
> > Ditto.
> >
> >> So I think it's up to you: If you thinking sorting will be useful in the
> >> future, then I think keep it.  But if you also think it's not going to
> >> be very useful, I think it would make more sense to take it out.
> >>
> > As we agreed elsewhere in the thread, let's keep it like this for now,
> > and see how it behaves. I'll keep an eye at it, and won't push for
> > keeping sort() instead of max() if shows to not provide any benefit.
> OK -- then I think we have a go-ahead to check in patches 8 and 9 (with 
> perhaps some changes to wording of some comments?).

Patch 8 had a crash whcih needs resolving first. I'm expecting Dario
will repost.

Ian.



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