| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
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.
Cheers,
Chris
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home