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 inter

To: Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>
Subject: Re: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface.
From: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Date: Thu, 16 Apr 2009 09:32:37 -0700
Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, "Tian, Kevin" <kevin.tian@xxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 16 Apr 2009 09:33:04 -0700
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: <2b060016-4fa6-4ab7-885e-263c468689ec@default>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird (X11/20090320)
Dan Magenheimer 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 don't see how it makes a difference. At the moment, you're never sure if a pair of vcpus are HT thread pairs, two cores on the same socket, or on completely different sockets - all of which will have quite different performance characteristics. And unless your server is under-committed, you're always running the risk that one domain is competing with another for CPU when it needs it most - and if you're under-committed, you can always pin everything in exactly the config you want.

Besides, the chances are good that the single-threaded performance of each core on your shiny new server will be fast enough to overcome the cost of HT compared to your old server...

Also, in the analysis below, the problem is greatly
simplified because today's (x86) processors are limited
to two hyperthreads.  How soon will we see more threads
per core, given that other non-x86 CPUs already support
four or more?

I think the simplifying factor is that the number of threads/cores you're ganging together is a relatively small proportion of the total number of available threads/cores, so the problem is under-constrained and there are lots of nearly-optimal solutions. If you're trying to gang schedule a large proportion of your total resources, then you get into tricky boxpacking territory.


Xen-devel mailing list

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