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

[Chris <hap10@xxxxxxxxxxxxxx>]

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.
Cheers,
Chris

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