[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 09 of 10 v3] libxl: have NUMA placement deal with cpupools

On 06/07/12 14:10, Dario Faggioli wrote:
On Fri, 2012-07-06 at 13:42 +0100, George Dunlap wrote:
libxl: have NUMA placement deal with cpupools

In such a way that only the cpus belonging to the cpupool of the
domain being placed are considered for the placement itself.

This happens by filtering out all the nodes in which the cpupool has
not any cpu from the placement candidates. After that -- as a cpu pooling
not necessarily happens at NUMA nodes boundaries -- we also make sure
only the actual cpus that are part of the pool are considered when
counting how much processors a placement candidate is able to provide.

Signed-off-by: Dario Faggioli<dario.faggioli@xxxxxxxxxx>
Acked-by: Ian Campbell<ian.campbell@xxxxxxxxxx>
If I'm reading this right, the filtering won't prevent duplicate entries
returned from get_numa_candidates; is that right?  I.e., suppose you
have a 4-node system and you run "xl cpupool-numa-split" to get one pool
per node.  Before this patch, your generator might return the following
sets containing node 0:

But now, if the domain is placed in a cpupool that has only numa node 0,
it will return 8 copies of {0}.  Is that correct?

It is. As the generation happens before cpupool are being considered at
all. Point is, while the number of cores could be quite high (and
continue to grow), the number of NUMA nodes in existing machines that
such a case won't hurt that much. Anyway, you're definitely right, it
would have been possible to do much better.

Maybe, if we're cool with patch 8, we can jut skip this for now, and
I'll resubmit a separate patch (where I'll deal with duplicates) like
later or on Monday?
Well, before discussing acking or nacking, I just wanted to establish that this is what the code did. The thing is, apart from re-writing your generator only to use nodes in the cpupool, the most efficient thing to get rid of duplicates is probably to do a sort anyway; so the end-to-end number of operations may end up similar either way.

Why don't we do this: let's check in this version, so we can start getting the cpu placement stuff tested. Then if there's time, you can post patches to do the filtering at the node generation stage rather than the filtering stage. Does that make sense?


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.