[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On Feb 4, 2008, at 5:56 PM, Keir Fraser wrote:
On 4/2/08 19:14, "Chris" <hap10@xxxxxxxxxxxxxx> wrote:
Hmmm... again the generic domgrp stuff seems like a huge amount of code with few moving parts that would affect user experience of Xen. The original schedgrps code by comparison is tiny. I don't mind taking big gobs of code if there are genuine use cases, but I won't big pieces of 'architecture'
without good reason. I'm inclined to take Mike's patches roughly as he
previously posted them.

Use cases for domain groups that exist today:
- domain management (e.g. group migration)
- scheduler integration (Mike's schedgrps)

Use cases coming down the pike:
- XSM integration (e.g. express policy in terms of groups)
- domain relationships (e.g. failure handling)
- resource management (e.g. allocating a resource to a set of domains)
- set_target/IS_PRIV_FOR integration (e.g. to establish privilege over a set of domains)

These use cases stem from where we see domain decomposition headed and the challenges it creates.

Can some notion of groups can be implemented in each case without an underlying VMM-backed, non-hierarchical group architecture? You bet. However, each implementation is likely to have a separate management interface and impose (possibly conflicting) hierarchies between domains. For such independent components to take advantage of one another, each would have to translate their respective notions of groups, assuming such a translation exists.

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.

Could domgrps be smaller? Yes, and thanks to Mike's recent suggestions, I have some concrete ways to make that happen. If you have some specific areas where you think domgrps is unnecessarily large, I'm willing to make changes. Another way to look at the code size issue is that the integration with schedgrps shaved off well over over 400 LOC, mostly by removing redundant management code from schedgrps. At that rate it would take two, maybe three more group- aware projects for the domgrps architecture to break even in terms of code size.

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.