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: Wed, 6 Feb 2008 10:22:28 -0500
Cc: "Mike D. Day" <ncmike@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 06 Feb 2008 07:22:41 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C3CF2C73.1C02C%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: <C3CF2C73.1C02C%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
On Feb 6, 2008, at 4:20 AM, Keir Fraser wrote:
If credit-sharing is made configurable (as you would surely want it to be if domgrps are to have other uses) then a reasonable number of those lines of
code will reappear, and spread across tools and hypervisor.

Without testing, I'd say that making the domgrps/schedgrps merge provide logically equivalent functionality to the original schedgrps requires the addition of 1 conditional statement in the VMM:

diff -r 82d60475e726 xen/common/domgrp.c
--- a/xen/common/domgrp.c       Wed Feb 06 09:01:54 2008 -0500
+++ b/xen/common/domgrp.c       Wed Feb 06 09:47:38 2008 -0500
@@ -215,7 +215,8 @@ int add_dom_to_grp(struct domain *dom, d

        /* add dom to schedgrp */
-       sched_join_group(dom); // FIXME: should be conditional/optional
+       if (dgid == NULL_GROUP_ID)
+               sched_join_group(dom);
        return ret;

In the domgrps model, all ungrouped domains are in the "null group." And in schedgrps model, all grouped domains automatically relinquish their VCPUs. So by preventing domains in the null group from relinquishing their VCPUs, the above change make the two implementations effectively equivalent: only explicitly grouped domains relinquish their VCPUs.

Additional configuration options will be desirable and will take code, but in this case domgrps hasn't created any new problems.

sharing scheduler credits with the HVM guest is a rather special case, and
one where a master/slave relationship is not unreasonable

I agree. It's not unreasonable, but it's also not strictly necessary. I would like to avoid any mechanism that induces a domain hierarchy without need.

If you really want resource sharing amongst a peer group of
domains, what does that actually mean? Does each domain have a private
allocation of resource plus membership of one or more pools? If so, which resource set satisfies each resource request by a particular domain? Even if not, how is resource contention between domains belonging to the resource pool (e.g., for the static assignment of memory pages to that resource pool) managed and resolved? The obvious place would be the dom0 control plane --
in which case these resource pools can probably be implemented as a
high-level tools abstraction with no direct hypervisor involvement at all.

It might be that, in the case of resource management, the VMM doesn't have to be involved, but the tool chain would benefit from a common configuration system and API to converse about groups of domains.

My fear is that a nice domgrps infrastructure doesn't itself resolve the hard devils in the details, for all that it sounds architecturally neat.

You're right, it definitely doesn't make the devils go away. My goal is more modest. I'm advocating for a common framework where tools and the VMM can use group information in a way that's relationship agnostic.


Xen-devel mailing list