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] [PATCH] Scheduling groups, credit scheduler support

To: <ncmike@xxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] Scheduling groups, credit scheduler support
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Tue, 04 Dec 2007 10:38:04 +0000
Delivery-date: Tue, 04 Dec 2007 02:39:10 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20071129201959.GC12559@xxxxxxxxxxxxxxxxxxxxxx>
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/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acg2Yb/w/lJmoqJUEdy0zwAX8io7RQ==
Thread-topic: [Xen-devel] [PATCH] Scheduling groups, credit scheduler support
User-agent: Microsoft-Entourage/11.3.6.070618
On 29/11/07 20:19, "Mike D. Day" <ncmike@xxxxxxxxxx> wrote:

> The credit implementation is limited to the sharing time slices among
> group members. All members of a group must share the master's time
> slices with the master. If the group master is capped at 20%, the
> cumulative total of the master and all members will be 20%. This is
> specifically to support stub domains, which will host the device model
> for hvm domains. The proper way to schedule a stub domain is for it to
> share the times slices allocated the the stub's hvm domain.

It's good to see these patches get aired again. I hope we can get some
integration with the ongoing stub domain work and get some numbers out to
prove better scalability and QoS. This would ease the passage of scheduler
group support into xen-unstable.

> The credit scheduler runs vcpus, not domains. However, a domain's
> vcpus are given time slices according to the credits available to the
> domain and any caps placed on the domain. Therefore, the simplest way
> to group domains together in the credit scheduler is to assign the
> member domain's vcpus to the master domain. Each vcpu assigned to the
> master domain receives a credit equal to the master domain's total
> credit divided by the number of assigned vcpus. This forces all the
> member domains to share the master domain's credits with the master,
> which achieves the desired behavior.

Is this the right thing to do? I would think that the desired behaviour is
for each 'master vcpu' to freely share its credit allocation with its 'buddy
vcpus'. The static N-way split of credits across vcpus within a domain makes
some kind of sense, since the vcpus are each equally important and each
independent of each other. Statically splitting credits between e.g., HVM
guest domain and its stub domain makes less sense. One is subordinate to the
other, and a model where the stub can 'steal' credits dynamically from the
HVM domain seems to make more sense. Otherwise, wouldn't a uniprocessor HVM
guest get half its credit stolen by the uniprocessor stub domain, even if
the HVM guest is doing no I/O?

Perhaps I misunderstand. :-)

 -- Keir




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