[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 08 of 10 v3] libxl: enable automatic placement of guests on NUMA nodes
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. 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 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |