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

[Samuel Thibault <samuel.thibault@xxxxxxxxxxxxx>]

Chris, le Tue 04 Dec 2007 14:32:11 -0500, a écrit :
> 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.

Yes, some kind of non-schedulable entity which is just here to do what
Mike's masters do: concentrate scheduling credits.

About the userland interface, I can see two approaches:
- have people explicitely create groups and put domains in it. That can
  be hierarchical (putting groups into other groups)
- have groups created and destroyed implicitely, for instance
join(d1,d2) will make d1 and d2 part of the same group, which is created
if there weren't any previously, or the union of both groups if both
existed.

The second approach seems fun, but I'm not sure it might ever be useful
actually :)

Also, there is the question: can a domain belong to several groups?
Depending on the point of view, that may be useful or just not make
any sense.  One problem of belonging to several groups is that you
end up with a graph of domains, which may be tedious and potentially
non-polynomial to walk.

Samuel

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