This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and inte

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface.
From: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
Date: Fri, 17 Apr 2009 11:17:02 +0100
Cc: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Delivery-date: Fri, 17 Apr 2009 03:17:28 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=WeGOzIhHE5nKqi5JM0W/tqBzjR1gx5KV9mIavJafdoE=; b=LyDQLE1vEGC3GxjgZLfzhZjKWaZQ/p6ZWOPU3xVjfRzuCB+mxYG/YSD6RDGSmfoTPr hiD3sTd4lvcYd19+cRlD/d3JYTtJ8fWuQ6ii7Zi4NWO//i2UbovhEvQiUs9nKAbUyn49 PpBJ6HVEOdNYqszd2SzmRpHpo55NWRuVTZTEc=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=VW00BVU5E+ncIq2THcMoEWwrm+pwvaERHKVV0RGQ4CuNuCWjIwDxBIBDmXoi9v3FK/ i2orUmpFHrs5X7V8XN8PrG8FIlzYsRmTfDmOg55yXL7czVWAbagql6zPeVp9YNZ2IiJL K3brt/afJZj7BCrOHANR4nNW9It7X8KBfa4UQ=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <2b060016-4fa6-4ab7-885e-263c468689ec@default>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <de76405a0904160327h29d138d1pfe6e4c2b4f4eaaac@xxxxxxxxxxxxxx> <2b060016-4fa6-4ab7-885e-263c468689ec@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, Apr 16, 2009 at 3:10 PM, Dan Magenheimer
<dan.magenheimer@xxxxxxxxxx> wrote:
> >From a resource utilization perspective, hyper-pairing may
> make sense.  But what about the user perspective?  How would
> an administrator specify hyper-pairing?  And more importantly
> why?  When consolidating workloads from, say, a group
> of dual-core or dual-processor servers onto some future
> larger hyperthreaded server, why would anyone say
> "please assign this to a hyper-pair", which is essentially
> saying "give me less peak performance than I had before"?

I think what you're saying is that when we only expose vcpus to the
guest, we can either run 2 vcpus on HT pairs, or give them an entire
core to themselves; but if we expose them as HT pairs and gang
schedule, then we're promising only to run them on HT pairs, limiting
the peak performance.

Hmm, I'm not sure that's actually true.  We could, if we had a
particularly idle system, split HT pairs and let them run as
independent vcpus.  I'm pretty sure the resulting throughput would be
usually higher.

In any case, it's a bit like asking, "Why would I buy a machine with
two hyperthreads instead of two cores?"  Yes, going from 2 vcpus to 2
vhts (virtual hyperthreads) is a step down in computing power; so
would going from a dual-core processor w/o HT to a single-core
processor with HT.  If you want to monotonically increase power, give
it 4 vhts.

At any rate, I think we can bring these up again when we actually
start to implement this feature.  First things first. :-)


Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>