RE: [Xen-devel] Cpu pools discussion

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

Sorry for the late join...

I wonder if cpu pools helps with the following problem:

Some large software company that shall remain nameless
continues to license their high value applications
on a per-pcpu basis rather than on a per-vcpu basis.
As a result, VMs running these applications must be
restricted to specific pcpu's which are "licensed" to
run the software.

Currently this is done with pinning, but pinning
does restrict the flexibility of a multi-vcpu VM.
Affinity seems like it should help, but affinity
doesn't restrict the VM from running on a non-affinitive
pcpu (does it?)

For example, assume you have an 8 vcpu VM and it
must be restricted to a 2 pcpu license on a
4 pcpu server.  Ideally, you'd like any of the 8
vcpus to be assigned to either pcpu at any time
so you don't want to pin, for example, even
vcpu's to pcpu#0 and odd vcpu's to pcpu#1.
And, if all vcpus are idle, you'd like pcpu#0
and pcpu#1 to be free to run other VMs.

Can this be done with cpu pools (easier than / more
flexibly than / and not at all ) with current pinning
and affinity?

Also in a data center, does cpu pools make it possible/
easier for tools to pre-assign a subset of processors
on ALL servers in the data center to serve a certain
licensed class of VMs?  For example, perhaps one
would like to upgrade some of the machines in one's
virtual data center from dual-core to quad-core but
not pay for additional per-pcpu app licenses (i.e.
the additional pcpus will be used for other non-licensed
VMs).  Tools could assign two pcpus on each server
to be part of the "DB pool" thus restricting execution
(and license fees) but still allowing easy migration.

Can this be done with cpu pools (easier than / more
flexibly than / and not at all ) with current pinning
and affinity?

If the answer to these questions is yes, than I
suspect one large software company might be very
interested in cpu pools.

> -----Original Message-----
> From: Juergen Gross [mailto:juergen.gross@xxxxxxxxxxxxxx]
> Sent: Tuesday, July 28, 2009 7:57 AM
> To: George Dunlap
> Cc: xen-devel@xxxxxxxxxxxxxxxxxxx; Zhigang Wang; Tim Deegan; 
> Keir Fraser
> Subject: Re: [Xen-devel] Cpu pools discussion
> 
> 
> George Dunlap wrote:
> > On Tue, Jul 28, 2009 at 2:39 PM, Juergen
> > Gross<juergen.gross@xxxxxxxxxxxxxx> wrote:
> >> I think your first point is the most important one.
> >> It might be possible to build a load balancing scheme to 
> shift cpus between
> >> pools dynamically, but this should be step 2, I think :-)
> >> But it would be a nice project :-)
> > 
> > If I recall your use case, Juergen, I thought the whole point was to
> > keep some set of VMs limited to just a subset of CPUs?  So the first
> > point is a feature for you, not a bug. :-)
> 
> Indeed.
> I just like to think about further enhancements, even if my 
> company isn't
> requiring them...
> 
> > 
> > If we ever do find someone who wants cpu pools, perhaps to use
> > different schedulers, but wants to be able to dynamically 
> adjust pool
> > size, then they can work on such a project.  Until then, no point
> > spending time on something no one's going to use.
> 
> Absolutely true.
> OTOH I see pools as an interesting way to support large NUMA 
> systems in an
> effective way. And for this usage you would need such a project :-)
> I think it is very important to check the possible future 
> enhancements, as
> they might influence decisions today.
> 
> 
> Juergen
> 
> -- 
> Juergen Gross                 Principal Developer Operating Systems
> TSP ES&S SWE OS6                       Telephone: +49 (0) 89 636 47950
> Fujitsu Technolgy Solutions               e-mail: 
> juergen.gross@xxxxxxxxxxxxxx
> Otto-Hahn-Ring 6                        Internet: ts.fujitsu.com
> D-81739 Muenchen                 Company details: 
> ts.fujitsu.com/imprint.html
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel
>

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel