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

Re: [Xen-devel] XEN Proposal

  • To: George Dunlap <dunlapg@xxxxxxxxx>
  • From: Juergen Gross <juergen.gross@xxxxxxxxxxxxxxxxxxx>
  • Date: Fri, 12 Dec 2008 07:09:22 +0100
  • Cc: Chris <hap10@xxxxxxxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Keir Fraser <keir.fraser@xxxxxxxxxxxxx>
  • Delivery-date: Thu, 11 Dec 2008 22:10:04 -0800
  • Domainkey-signature: s=s768; d=fujitsu-siemens.com; c=nofws; q=dns; h=X-SBRSScore:X-IronPort-AV:Received:X-IronPort-AV: Received:Received:Message-ID:Date:From:Organization: User-Agent:MIME-Version:To:CC:Subject:References: In-Reply-To:X-Enigmail-Version:Content-Type: Content-Transfer-Encoding; b=gGRH5eE05/fjQEQfsfwGfKSS7l3M5Zq7RC2344cmi7UTwCaUSgfRNvYH pMWqdVXZfHfyfNcmuYyV+TeWj8rl4ibCPXHzBJh4KNJEe2zzNBA5JbT66 ALKlEpMlxEiMxhe;
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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.


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



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