Re: [Xen-devel] [0/3] DomGrp/SchedGrp Merge RFC
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
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)
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
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,
resource set satisfies each resource request by a particular
domain? Even if
not, how is resource contention between domains belonging to the
pool (e.g., for the static assignment of memory pages to that
managed and resolved? The obvious place would be the dom0 control
in which case these resource pools can probably be implemented as a
high-level tools abstraction with no direct hypervisor involvement
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
hard devils in the details, for all that it sounds architecturally
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
Xen-devel mailing list