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 Jackson <Ian.Jackson@eu.citrix.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
	Ian Campbell <Ian.Campbell@citrix.com>,
	Stefano Stabellini <Stefano.Stabellini@eu.citrix.com>,
	George Dunlap <George.Dunlap@eu.citrix.com>,
	Juergen Gross <juergen.gross@ts.fujitsu.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:47:56 +0200	[thread overview]
Message-ID: <1342604876.19530.124.camel@Solace> (raw)
In-Reply-To: <1342570947.11794.92.camel@Abyss>

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

On Wed, 2012-07-18 at 02:22 +0200, Dario Faggioli wrote:
> Moreover, as another input parameter is a nodemask, telling the
> algorithm not only how many but also _which_ nodes it should consider,
> one could imagine to have some multi-tier form of the algorithm itself,
> or, perhaps, implementing a more abstract and coarse partitioning
> heuristics among group of nodes (which will better be done as soon as
> we'll see how 32 and 64 nodes system will actually look like :-D) and
> then run the current algorithm only on these groups, with numbers that
> would then look just like above.
> 
Alternatively (or maybe not even that much 'alternatively' :-)), we can
try turning it into something a bit more greedy, e.g., searching for
available placement solutions just as big as min_nodes says (typically
1) as a first step (complexity linear with the number of nodes).

After that, if we did not find anything, we could have some sort of
config switch telling us if we should continue, and maybe investigating
candidates of sizes in the range [min_nodes+1,LIBXL__MAX_GUEST_NODES]. 

At which point, if we haven't found anything yet, we could just give up
or, perhaps, think and implement in the near future a more coarse and
less precise mechanism for proceeding further.

Implementing something like that on top of what I have now (which I'll
resend asap, as soon as I've addressed the minor comments I got) during
4.3 should be pretty easy. Also, if we decide to just statically limit
max_nodes<=LIBXL__MAX_GUEST_NODES (or whatever we could call it) to
something (I was proposing 4 in the other e-mail) for 4.2, backporting
to it will be piece of cake as well. :-)

Thanks again 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)

-- 
<<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