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] [0/3] DomGrp/SchedGrp Merge RFC

To: Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [0/3] DomGrp/SchedGrp Merge RFC
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 06 Feb 2008 11:00:19 +0000
Cc: Chris <hap10@xxxxxxxxxxxxxx>, "Mike D. Day" <ncmike@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 06 Feb 2008 03:08:12 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20080206104212.GB4338@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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: Achor3YZtITacNSiEdy8iQAX8io7RQ==
Thread-topic: [Xen-devel] [0/3] DomGrp/SchedGrp Merge RFC
User-agent: Microsoft-Entourage/
On 6/2/08 10:42, "Samuel Thibault" <samuel.thibault@xxxxxxxxxxxxx> wrote:

>> Well that sounds plausible, but I'm not sure how resource pools or domgrps
>> would help with that. It sounds like a delegation mechanism (of privilege
>> and/or resource) would be more appropriate.
> Sure, delegation will be needed, but there needs to be a way to specify
> which domains that scheduler has control on.

It's not clear to me that supporting any more than a delegation relation
across pairs of domains is needed at the hypervisor level. Nor whether a
richer grouping mechanism in this case would lead to greater run-time
efficiency, fewer lines of code, or clearer code.

 -- Keir

Xen-devel mailing list