[Xen-devel] Re: 0/4 Xen Scheduling Groups

["Mike D. Day" <ncmike@xxxxxxxxxx>]

On 14/05/07 18:27 -0400, Chris wrote:
> I'm happy to see other folks interested in the concept of domain groups
> because it relates to some of my work.  We seem to share many common
> goals.  Particularly, we both made use of the hypervisor to support
> groups of domains.  My first impressions:
>
> Master/Slave Roles
> ------------------
> While the master/slave model is certainly popular, it is not the only
> relationship between domains.  Consider a groups of peers.  One way to
> associate domains without an implicit hierarchy is to make groups a
> first-class object, just like domains.  You can anchor scheduling
> information against the group instead of on a single domain.  This
> approach also has the benefit of allowing other projects to use group
> information for more than scheduling.
This is a good idea. When I made my first attempt at scheduling groups
I put the infrastructure in place to make groups a first-class
object. However, I decided to rewrite the code to push most the
changes into the credit scheduler because doing so dramatically
reduced the size of the patches, and it made the patches more discrete
and modular.

I feel that starting out with a minimal patchset that meets the
specific requirements (accurate scheduling of stub domains) was the
right first step. Extending the concept of groups within Xen is a good
next step.

> Usability
> ---------
> Assuming I read your patches correctly, the intended use is that
> administrators must remember which domains are masters and which are
> members (and do so by domid).  Since it's easy to lose track of domids,
> I suggest augmenting xm list and the supporting infrastructure to
> provide cues to the administrator about group membership and roles.
Yes, that is definitely needed. 

> Also, it would seem sched-group.c supports specification of members by
> domid only.  Support for using domain names and uuids would be useful
> because domids do change.
Yes, very true. This is probably best implemented in the tools
themselves. 

> Assigning group names and group uuids quickly becomes essential too.
> Imagine the chore of finding one member domain among many groups using
> only the master's domid.  Reboots, migration, suspend/resume and
> save/restore all change the domid, making it much more difficult.  This
> leads me to my next questions...
>
> Migration
> ---------
> What happens when any of the group members migrate?  Ditto for
> suspend/resume and save/restore.  Automatically rebuilding groups after
> these events is crucial.  So, it would be nice to see preservation of
> the group association across the full lifecycle of domains.
Right now groups are an ephemeral object. They are destroyed when the
group master domain is destroyed (or migrated). Groups are easy to
re-compose using a hypercall, and I haven't seen a use case that would
disallow re-composition of groups after a short interval rather than
abosolute persistence. Without the requirement absolute persistence
I'm not sure this too also cannot be best be implemented using tools. 

What are you using domain groups for? 

Mike

--
Mike D. Day
IBM LTC
Cell: 919 412-3900
Sametime: ncmike@xxxxxxxxxx AIM: ncmikeday  Yahoo: ultra.runner
PGP key: http://www.ncultra.org/ncmike/pubkey.asc

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