xen-devel
RE: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and inter
> But if this is a big issue, you can always disable HT, as
> lots of people did the last time around.
That would be a shame because HT will almost certainly
provide SOME performance benefit MOST of the time.
After pondering a bit, I guess I am arguing that once
processors have HT, Turboboost, and power management,
scheduling as a discipline has to move from the realm
of discrete to the realm of continuous. A "second of
CPU" no longer has any real meaning when the value
of "a CPU" varies across time and workload. (I suppose
due to shared cache effects and bus contention, this has
probably always been the case, but to a less obvious
degree.)
> The only way to know is by measurement, ideally with
> some specific performance counter which tells you
> what went on in that last timeslice.
Indeed. Even if it is impossible to predict the
throughput of a specific workload on a specific CPU,
it sure would be nice if we could at least roughly
measure the past.
Processor architects take note! ;-)
> -----Original Message-----
> From: Jeremy Fitzhardinge [mailto:jeremy@xxxxxxxx]
> Sent: Friday, April 17, 2009 10:17 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:
> > 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.
> >
>
> Actually the 70% was a number I plucked out of the air with no
> justification at all.
>
> > 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?)
> >
>
> The only way to know is by measurement, ideally with some specific
> performance counter which tells you what went on in that last
> timeslice. But if this is a big issue, you can always disable HT, as
> lots of people did the last time around.
>
> J
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- RE: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface., (continued)
- Re: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface., George Dunlap
- RE: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface., Dan Magenheimer
- Re: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface., Jeremy Fitzhardinge
- RE: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface., Dan Magenheimer
- Re: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface., Jeremy Fitzhardinge
- Re: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface., George Dunlap
- RE: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface.,
Dan Magenheimer <=
- RE: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface., Tian, Kevin
Re: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface., George Dunlap
RE: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface., Tian, Kevin
Re: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface., Zhiyuan Shao
|
|
|