Re: [Xen-devel] Re: Scheduling groups, credit scheduler support

[Chris <hap10@xxxxxxxxxxxxxx>]

First let me restate that this is a great use for groups.

> The patches use the term master and member, but it is more of a peer
> relationship only effecting scheduler accounting. The significance of
> the "master" is that the "member" domains inherit the master's cpu
> weight and credits are charged to the master. The master doesn't exert
> any explicit control over its group members (although there may be a
> use case for doing so). This is the specific functionality we need for
> stub domains, where the credits consumed by a stub domain need to be
> charged to the HVM guest domain.
A primary concern is that the approach potentially precludes the use  
of VMM-based grouping information in other situations where groups  
are useful because the group abstraction exists only in the scheduler.
Also, even though it's currently just used for accounting, group  
membership information is effectively attached to a single domain.   
Assuming I've read correctly, when the master domain goes away, so  
does the membership information.  That's probably OK for HVM stub  
domains, but what if the domains are peers as in the dom0  
disaggregation case or (thinking even further ahead) in the general  
domain decomposition case?
One way to avoid both concerns is to create and manage group-tracking  
objects independently of domain-tracking objects.   In other words,  
make groups a first-class object.  They could be referenced by  
schedulers as well as any other parts of the VMM that want to make  
use of group information.
Regards,
Chris

P.S. - A refresh of my previous group implementation is coming RSN.  
I'm testing to make sure it still works as intended. 
 

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