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

From: Dario Faggioli <raistlin@linux.it>
To: George Dunlap <george.dunlap@eu.citrix.com>
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, 06 Jul 2012 16:35:17 +0200	[thread overview]
Message-ID: <1341585317.15708.65.camel@Abyss> (raw)
In-Reply-To: <4FF6E29E.3010006@eu.citrix.com>

[-- Attachment #1.1: Type: text/plain, Size: 2514 bytes --]

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 #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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