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

From: George Dunlap <george.dunlap@eu.citrix.com>
To: Dario Faggioli <raistlin@linux.it>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	"xen-devel@lists.xen.org" <xen-devel@lists.xen.org>,
	Roger Pau Monne <roger.pau@citrix.com>
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	[thread overview]
Message-ID: <4FF6F8E7.9010808@eu.citrix.com> (raw)
In-Reply-To: <1341585317.15708.65.camel@Abyss>

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?).

  -George