[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.