Re: [Xen-devel] [0/3] DomGrp/SchedGrp Merge RFC

[Chris <hap10@xxxxxxxxxxxxxx>]

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
        grp->size++;

        /* add dom to schedgrp */
-       sched_join_group(dom); // FIXME: should be conditional/optional
+       if (dgid == NULL_GROUP_ID)
+               sched_join_group(dom);
       out:
        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.
-Chris

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