Re: [Xen-devel] XEN Proposal

[Juergen Gross <juergen.gross@xxxxxxxxxxxxxxxxxxx>]

George Dunlap wrote:
> On Thu, Dec 11, 2008 at 6:23 AM, Juergen Gross
> <juergen.gross@xxxxxxxxxxxxxxxxxxx> wrote:
>>> The software prices for BS2000 will be still related to the machine power.
>> But often customers need only a small portion of the complete x86 machine
>> power for BS2000, so we added a license scheme to limit the power available
>> to BS2000 by pinning the domains with BS2000 to a subset of cpus.
> 
> OK, so... you sell software, and the cost of it depends on how
> powerful a machine you run it on.  But most people don't need even one
> full core's worth of power.  You want to be able to charge people who
> need a full core of processing power one price, and charge people who
> need only say, 20%, less?  So to artificially limit the power
> available to a given instance, you pin all instances to some subset of
> cpus?

More or less.
But the processors of our servers are 6-core. A customer might want to pay
for only some cores of power.

> 
> I presume then, that there are multiple instances, and people pay for
> how many cores they can use total...?  And that your customers
> generally have other things running on the server as well.

Correct.

> 
> It seems like what you really want is to cap the number of credits the
> VMs can get, and then take them offline when their credits go negative
> (instead of competing for resources in a "best-effort" fashion).  :-)

In theory, yes.
But if a customer has a license for the power of 3 cores for BS2000, he
should be able to run for example 4 BS2000 domains which must not consume
more power in sum, but if 3 domains are more or less idle, the remaining
domain could take all 3 cores.
I don't think this is an easy job with caps.

> 
> However, it does seem like being able to partition up a Xen server
> into "pools" of cpu resources, each with its own scheduler, that don't
> compete with each other, might be generally useful.  It should be
> relatively straightforward to slide in under the current scheduler
> architecture, without having to change much in the schedulers
> themselves.  That's how I'd prefer it done, if possible: a clean layer
> underneath a scheduler.

That is the direction I would go.


Juergen

-- 
Juergen Gross                             Principal Developer
IP SW OS6                      Telephone: +49 (0) 89 636 47950
Fujitsu Siemens Computers         e-mail: juergen.gross@xxxxxxxxxxxxxxxxxxx
Otto-Hahn-Ring 6                Internet: www.fujitsu-siemens.com
D-81739 Muenchen         Company details: www.fujitsu-siemens.com/imprint.html

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