Re: [PATCH 1 of 3 v5/leftover] libxl: enable automatic placement of guests on NUMA nodes [and 1 more messages]

From: Dario Faggioli <raistlin@linux.it>
To: Ian Campbell <Ian.Campbell@citrix.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.com>,
	Ian Jackson <Ian.Jackson@eu.citrix.com>,
	xen-devel <xen-devel@lists.xen.org>
Subject: Re: [PATCH 1 of 3 v5/leftover] libxl: enable automatic placement of guests on NUMA nodes [and 1 more messages]
Date: Wed, 18 Jul 2012 11:43:36 +0200	[thread overview]
Message-ID: <1342604616.19530.123.camel@Solace> (raw)
In-Reply-To: <1342602839.26734.6.camel@zakaz.uk.xensource.com>

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

On Wed, 2012-07-18 at 10:13 +0100, Ian Campbell wrote:
> On Wed, 2012-07-18 at 01:22 +0100, Dario Faggioli wrote:
> 
> > So, to summarize, I can't be farther than saying the current algorithm
> > is perfect or fast. Rather, I'm definitely saying it has the advantage
> > of not branching out the problem space too much aggressively at this
> > early stage, and it is flexible enough for avoiding getting unreasonable
> > performances, or at least, it looks like that to me, I guess. :-)
> 
> I'm not quite following what you are trying to say with all this.
> 
Oh, I see, sorry. :-(

> Are you saying that the code as most recently submitted does not have
> the O( C(nr_nodes,min_nodes) ) property which Ian J suggests, which
> leads to needing to process hundreds of millions of combinations for a
> 16 / 32 node guest? 
>
No, I'm not. If you want to place a 16 (32) nodes guest on a 32 (64)
nodes host, it is as bad as he says. However, I'm also saying that on
<=16 nodes host it is able o provide very good placement at a reasonable
cost and that, if we limit the number of guest nodes (e.g., up to 4) it
is able to do the same even on 32 or 64 nodes hosts.

> Or are you saying that it does have this property
> but it doesn't matter? 
>
A lot of people is thinking that trying to address the problem of
placing guests that are bigger (or anyway, guests that does not fit) in
just 1 node should not be even considered. I'm saying that it should and
am also proposing an algorithm that is able to provide good placement
performances for guests that spans up to 4 nodes even on future 32 or 64
nodes systems.

So basically I'm saying that it does have that property but that is
bringing benefits right now, and we have all the knobs to limit its
potential nasty effects for future (bigger) system at any time.

> Or are you saying it does have this property but
> you intend to ameliorate it somehow? If the latter then how and for
> which release(s) (4.2, 4.3 or 4.2.1)?
> 
Yes, I guess I'm sort of saying something like that.
What could be done is restricting automatic placement to guests that
fits on 4 or 8 nodes for 4.2. Then, for 4.3 (and with a very small
backport effort to 4.2.1), implement a lighter solution for dealing with
the ones that does not.

Hope I clarified at least a bit. :-)

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