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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("Re: [PATCH 1 of 3 v5/leftover] libxl: enable automatic 
placement of guests on NUMA nodes [and 1 more messages]"):
> On Wed, 2012-07-18 at 10:43 +0100, Dario Faggioli wrote:
> > What could be done is restricting automatic placement to guests that
> > fits on 4 or 8 nodes for 4.2.
> 
> 8 would mean on a 32 node system considering 10,518,300 combinations?
> 
> 4 would mean on a 32 node system considering 35,960 combinations? On a
> 64 node system it would mean 635,376 combinations.
> 
> If that's the case then lets go with 4 as the limit for 4.2.0.

What is the maximum number of NUMA nodes we might expect to see on a
single system in the next five years?  I would argue that 32 is too
optimistic.  128 or 256 seem like more reasonable upper bounds.  4 of
256 is 174,792,640 combinations - ie too many.  So there needs to be a
limit on the host size too.  But if you pick an upper host size limit
of 64 then in a hypothetical 128-node system you'd fail to do the
trivial search for a 1-node guest.

An upper bound on log(number_of_combinations) is
log(number_of_nodes_on_the_host) * number_of_nodes_for_the_guest.
This fact could be used to determine more accurately whether the
algorithm is going to terminate in a reasonable time.

Also when this algorithm would be used, but would take too long, we
should print a warning which tells the user they should use cpupools
to assign nodes directly.

Ian.

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