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

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> 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