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: Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: Re: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface.
From: Andrew Lyon <andrew.lyon@xxxxxxxxx>
Date: Thu, 16 Apr 2009 19:20:39 +0100
Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Delivery-date: Thu, 16 Apr 2009 11:21:17 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=KTqB4VLQ75xQj736ww1e5ERNN0FMoBHDDLnhsPPr5wQ=; b=qF+9QQwgx19Il/bQll2tP9hT0l8CihZ3JPdoqB8BnS9wI5U93YfTmcWoEV7urSBJ7N W5Xkg+kfFhduV/UMeUaFPFpORXuGRhztppDNKg0sk/KcE4m8FcqEwOqnHKhuLoY4uX+K YHdi4Y0WmvTHiyuy6OYLD2QSM9BSBdecvKIQs=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=MKctBPL685YBcMP2h3IukHgEseKhFYmxHhDHLiM8MySUqF8annT2zCDZENllYjDFo6 JvfE6o21tifkMumfHwMy4HOn1XknOMHGM9vRRRlUnrCfJfwrGuNZtlJhuOe6BNIcIKCw AtHWx5513abHO6p/8w158+CiCEFDnmxS4CktE=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <49E75DA5.70502@xxxxxxxx>
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> <49E75DA5.70502@xxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Thu, Apr 16, 2009 at 5:32 PM, Jeremy Fitzhardinge <jeremy@xxxxxxxx> wrote:
> 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...

Is HT particularly worthwhile for virtualization loads? we have
several older servers which have ht and I found that when running
windows terminal services it actually slowed the machine down, and
under certain circumstances it seemed to cause the system to become
extremely slow and had to be rebooted, we disabled ht and the problem
went away.

Many documents on the web recommend disabling ht for specific
workloads, and most benchmarks show that when it is benificial the
performance gain is quite small.

Or is your plan to make use of ht in a way that gets the most benefit
with no impact under edge cases?


>> 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.
>   J
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel

Xen-devel mailing list

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