WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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

<Prev in Thread] Current Thread [Next in Thread>