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/
Home Products Support Community News


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

To: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface.
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Sat, 11 Apr 2009 17:57:30 +0800
Accept-language: en-US
Acceptlanguage: en-US
Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sat, 11 Apr 2009 02:58:24 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4FA716B1526C7C4DB0375C6DADBC4EA34172EC1C9C@xxxxxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <de76405a0904090858g145f07cja3bd7ccbd6b30ce9@xxxxxxxxxxxxxx> <49DE415F.3060002@xxxxxxxx> <0A882F4D99BBF6449D58E61AAFD7EDD61036A60D@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <49DF708F.6070102@xxxxxxxx> <4FA716B1526C7C4DB0375C6DADBC4EA34172EC1C9C@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acm596nYrdHKNuOmRXW6VwLlP+rKwgABWn1AACOdXDA=
Thread-topic: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface.
>From: Ian Pratt [mailto:Ian.Pratt@xxxxxxxxxxxxx] 
>Sent: 2009年4月11日 1:16
>> 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.

what do you mean by 'free-for-all'? 

Xen-devel mailing list
<Prev in Thread] Current Thread [Next in Thread>