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: Chris <hap10@xxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [0/3] DomGrp/SchedGrp Merge RFC
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Wed, 06 Feb 2008 09:20:51 +0000
Cc: "Mike D. Day" <ncmike@xxxxxxxxxx>, xen-devel <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Wed, 06 Feb 2008 01:24:59 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <0AACAAE6-C2F5-44AE-AB0B-455D25DF132C@xxxxxxxxxxxxxx>
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: AchooZDkz7TlRNSUEdygDwAX8io7RQ==
Thread-topic: [Xen-devel] [0/3] DomGrp/SchedGrp Merge RFC
User-agent: Microsoft-Entourage/
On 5/2/08 22:20, "Chris" <hap10@xxxxxxxxxxxxxx> wrote:

> 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.

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.

> 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.

I'm driven by concrete use cases. Several of the upcoming uses you mention
need careful consideration of what they are useful for, to determine the
best way to design them into the system. Take resource sharing. Stub domains
sharing scheduler credits with the HVM guest is a rather special case, and
one where a master/slave relationship is not unreasonable (and hence in this
case I think it is arguable whether it is actually a good fit with domgrps
after all). 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.

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.

 -- Keir

Xen-devel mailing list