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: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, Jeremy Fitzhardinge <jeremy@xxxxxxxx>
Subject: RE: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface.
From: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>
Date: Sat, 11 Apr 2009 18:11:48 +0100
Accept-language: en-US
Acceptlanguage: en-US
Cc: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>, Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, "xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Sat, 11 Apr 2009 10:14:09 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <0A882F4D99BBF6449D58E61AAFD7EDD61036AB18@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acm596nYrdHKNuOmRXW6VwLlP+rKwgABWn1AACOdXDAACvrkYA==
Thread-topic: [Xen-devel] [RFC] Scheduler work, part 1: High-level goals and interface.
> >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>