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

[Jeremy Fitzhardinge <jeremy@xxxxxxxx>]

Ian Pratt wrote:
> > I don't know what the performance characteristics of modern-HT is, but
> > in P4-HT the throughput of a given thread was very dependent on what the
> > other thread was doing. If its competing with some other arbitrary
> > domain, then its hard to make any estimates about what the throughput
> > of a given vcpu's thread is.
> >     
> The original Northwood P4's were fairly horrible as regards performance 
> predictability, but things got considerably better with later steppings. 
> Nehalem has some interesting features that ought to make it better yet.
>
> Presenting sibling pairs to guests is probably preferable (it avoids any 
> worries about side channel crypto attacks), but I certainly wouldn't restrict 
> it to just that: server hosted desktop workloads often involve large numbers of 
> single VCPU guests, and you want every logical processor available.
>
> Scaling the accounting if two threads share a core is a good way of ensuring 
> things tend toward longer term fairness.
>
> Possibly having two modes of operation would be good thing:
>
>  1. explicitly present HT to guests and gang schedule threads
>
>  2. normal free-for-all with HT aware accounting.
>
> Of course, #1 isn't optimal if guests may migrate between HT and non-HT systems.
>   
This can probably be extended to Intel's hyper-dynamic flux mode (that 
may not be the real marketing name), where it can overclock one core if 
the other is idle.
   J

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel