From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeremy Fitzhardinge Subject: Re: [RFC] Scheduler work, part 1: High-level goals and interface. Date: Thu, 16 Apr 2009 09:32:37 -0700 Message-ID: <49E75DA5.70502@goop.org> References: <2b060016-4fa6-4ab7-885e-263c468689ec@default> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <2b060016-4fa6-4ab7-885e-263c468689ec@default> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer Cc: George Dunlap , "Tian, Kevin" , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.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