[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Re: 0/4 Xen Scheduling Groups
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 toolsthemselves. 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 persistenceI'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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |