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

[Andrew Lyon <andrew.lyon@xxxxxxxxx>]

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?

Andy


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