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: Sun, 12 Apr 2009 14:27:02 +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 23:27:33 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <4FA716B1526C7C4DB0375C6DADBC4EA34172EC1CA1@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> <0A882F4D99BBF6449D58E61AAFD7EDD61036AB18@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <4FA716B1526C7C4DB0375C6DADBC4EA34172EC1CA1@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acm596nYrdHKNuOmRXW6VwLlP+rKwgABWn1AACOdXDAACvrkYAAgCASw
Thread-topic: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface.
>From: Ian Pratt [mailto:Ian.Pratt@xxxxxxxxxxxxx] 
>Sent: 2009年4月12日 1:12
>> >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'?
>Same as today, i.e. we don't gang schedule and all threads are 
>available for running VCPUs. 
>I think it's reasonable to have two different modes of 
>operation. For some CPU-intensive server virtualization-type 
>workloads the admin basically wants to partition the machine. 
>In this situation it's reasonable to expose the physical 
>topology to guests (not just hyperthreads, but potentially 
>cores/sockets/nodes and all the gory SLIT/SRAT tables stuff too). 
>For more general virtualization workloads where the total 
>number of VCPUs is rather greater than the number of physical 
>CPUs then the current behaviour is preferable. HT aware 
>accounting will mean that VCPUs that run concurrently on the 
>same core will be charged less than the full period they are 
>scheduled for.


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