[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.
> I think you're over-complicating it. Perhaps. Or maybe you are oversimplifying it? ;-) > At very worst, it will > be no worse > than the current situation where Xen will place the vcpus on > threads/cores in more or less arbitrary ways. Agreed. Treating threads as cores is bad. Since that's what's happening today, one would think that any fix is better than nothing. > a contended HT thread is only worth, say, 70% of a > "real" core > : > (Another way to look at it is that HT contention is a bit like having > your vcpu being preempted by Xen, but rather than going from 100% > running to 0% running, your vcpu drops to 70%.) And that's the oversimplification I think. Just because Intel provides a rule-of-thumb that the extra thread increases performance by 30% doesn't mean that it is a good number to choose for scheduling purposes. I suspect (and maybe this has even already been proven) that this varies from 0%-100% depending on the workload, and may even vary from *negative* to *more* than 100%. (Yes, I understand that i7 is supposed to be better than the last round of HT... but is it always better?) Dan > -----Original Message----- > From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx] > Sent: Friday, April 17, 2009 8:56 AM > To: Dan Magenheimer > Cc: George Dunlap; Tian, Kevin; xen-devel@xxxxxxxxxxxxxxxxxxx > Subject: Re: [Xen-devel] [RFC] Scheduler work, part 1: > High-level goals > and interface. > > > Dan Magenheimer wrote: > >> 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. > > > > I think you're over-complicating it. At very worst, it will > be no worse > than the current situation where Xen will place the vcpus on > threads/cores in more or less arbitrary ways. > > I think George's proposal can already accommodate the user > needs you're > talking about: > > If the scheduler accounts for time spent executing on a contended HT > thread (ie, the threads are not paired, so the other thread could be > idle or running any other code) at a lesser rate than a full > core/uncontended thread, then the charging works out. > > If the user has a requirement that domain X's vcpus must be > running at > full speed, then they can set their reservation to 100%. If > we say that > a contended HT thread is only worth, say, 70% of a "real" core, then > that not only factors into the charging, but also means that > any domain > with a reservation > 70% is ineligible to run on a contended > HT thread. > (I think in practise this means that any domain with high > reservations > will end up running on gang scheduled thread pairs, just to guarantee > that the other thread is idle, so the uncontended HT thread > can run at > 100%.) > > (Another way to look at it is that HT contention is a bit like having > your vcpu being preempted by Xen, but rather than going from 100% > running to 0% running, your vcpu drops to 70%.) > > 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |