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: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [0/3] DomGrp/SchedGrp Merge RFC
From: Chris <hap10@xxxxxxxxxxxxxx>
Date: Tue, 5 Feb 2008 17:20:02 -0500
Cc: "Mike D. Day" <ncmike@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 05 Feb 2008 14:20:15 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C3CD48A2.13480%Keir.Fraser@xxxxxxxxxxxx>
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>
References: <C3CD48A2.13480%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Feb 4, 2008, at 5:56 PM, Keir Fraser wrote:
On 4/2/08 19:14, "Chris" <hap10@xxxxxxxxxxxxxx> wrote:
Hmmm... again the generic domgrp stuff seems like a huge amount of code with few moving parts that would affect user experience of Xen. The original schedgrps code by comparison is tiny. I don't mind taking big gobs of code if there are genuine use cases, but I won't big pieces of 'architecture'
without good reason. I'm inclined to take Mike's patches roughly as he
previously posted them.

Use cases for domain groups that exist today:
- domain management (e.g. group migration)
- scheduler integration (Mike's schedgrps)

Use cases coming down the pike:
- XSM integration (e.g. express policy in terms of groups)
- domain relationships (e.g. failure handling)
- resource management (e.g. allocating a resource to a set of domains)
- set_target/IS_PRIV_FOR integration (e.g. to establish privilege over a set of domains)

These use cases stem from where we see domain decomposition headed and the challenges it creates.

Can some notion of groups can be implemented in each case without an underlying VMM-backed, non-hierarchical group architecture? You bet. However, each implementation is likely to have a separate management interface and impose (possibly conflicting) hierarchies between domains. For such independent components to take advantage of one another, each would have to translate their respective notions of groups, assuming such a translation exists.

On the issue of code size, take Mike's schedgrps for example, which was very small as originally posted. After integration with domgrps, it shrank to less than 40% of its original size (259 insertions down from 681) and it no longer induced a domain hierarchy.

Could domgrps be smaller? Yes, and thanks to Mike's recent suggestions, I have some concrete ways to make that happen. If you have some specific areas where you think domgrps is unnecessarily large, I'm willing to make changes. Another way to look at the code size issue is that the integration with schedgrps shaved off well over over 400 LOC, mostly by removing redundant management code from schedgrps. At that rate it would take two, maybe three more group- aware projects for the domgrps architecture to break even in terms of code size.

But it sounds like the main objection is lack of existing use cases. They're coming... slowly. The best I can say is that I'm working to identify and mitigate future challenges before they cause problems. Is there critical mass for a generic group architecture yet? I think so, but the case should only get stronger with time.


Xen-devel mailing list