[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.
> In any case, it's a bit like asking, "Why would I buy > a machine with two hyperthreads instead of two cores?" Yes. In a physical machine, the OS takes advantage of all resources available. So it doesn't matter if some of the "processors" are cores and some are hyperthreads. You are using ALL of the CPU resources you paid for. But in a virtualized environment, each VM gets a fraction of the resources and if grabbing some fixed number of "processors" sometimes gets hyperthreads and sometimes gets cores, this will cause interesting issues for some workloads. Think about a cloud where one pays for resources used. You likely would demand to pay less for a hyperpair than a non-vht pair. As a result, I think it will be a requirement that a system administrator be able to specify "I want two FULL cores" vs "I am willing to accept two hyperthreads". And once you get beyond hyperpairs, this is going to get very messy. > At any rate, I think we can bring these up again when > we actually start to implement this feature. First > things first. :-) Well yes and no. While I am a big fan of iterative prototyping, I wonder if this might be a case where the architecture should drive the design and the design should drive the implementation. IOW, first think through what choices a system admin should be able to make (and, if given a mind-boggling array of choices, which ones he/she WOULD make). Just my two cents... > -----Original Message----- > From: George Dunlap [mailto:George.Dunlap@xxxxxxxxxxxxx] > Sent: Friday, April 17, 2009 4:17 AM > To: Dan Magenheimer > Cc: Tian, Kevin; Jeremy Fitzhardinge; xen-devel@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Xen-devel] [RFC] Scheduler work, part 1: > High-level goals > and interface. > > > On Thu, Apr 16, 2009 at 3:10 PM, Dan Magenheimer > <dan.magenheimer@xxxxxxxxxx> 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 think what you're saying is that when we only expose vcpus to the > guest, we can either run 2 vcpus on HT pairs, or give them an entire > core to themselves; but if we expose them as HT pairs and gang > schedule, then we're promising only to run them on HT pairs, limiting > the peak performance. > > Hmm, I'm not sure that's actually true. We could, if we had a > particularly idle system, split HT pairs and let them run as > independent vcpus. I'm pretty sure the resulting throughput would be > usually higher. > > In any case, it's a bit like asking, "Why would I buy a machine with > two hyperthreads instead of two cores?" Yes, going from 2 vcpus to 2 > vhts (virtual hyperthreads) is a step down in computing power; so > would going from a dual-core processor w/o HT to a single-core > processor with HT. If you want to monotonically increase power, give > it 4 vhts. > > At any rate, I think we can bring these up again when we actually > start to implement this feature. First things first. :-) > > -George > _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |