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

[Dan Magenheimer <dan.magenheimer@xxxxxxxxxx>]

> 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