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

[Jeremy Fitzhardinge <jeremy@goop.org>]

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.

    J