From mboxrd@z Thu Jan 1 00:00:00 1970 From: George Dunlap Subject: Re: [PATCH 08 of 10 v3] libxl: enable automatic placement of guests on NUMA nodes Date: Fri, 6 Jul 2012 15:40:39 +0100 Message-ID: <4FF6F8E7.9010808@eu.citrix.com> References: <7087d3622ee2051654c9.1341418687@Solace> <4FF6CC5C.1060905@eu.citrix.com> <1341579635.15708.17.camel@Abyss> <4FF6E29E.3010006@eu.citrix.com> <1341585317.15708.65.camel@Abyss> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1341585317.15708.65.camel@Abyss> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Dario Faggioli Cc: Andre Przywara , Ian Campbell , Stefano Stabellini , Juergen Gross , Ian Jackson , "xen-devel@lists.xen.org" , Roger Pau Monne List-Id: xen-devel@lists.xenproject.org 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< 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?). -George