WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Chris <hap10@xxxxxxxxxxxxxx>
Subject: [Xen-devel] Re: Scheduling groups, credit scheduler support
From: "Mike D. Day" <ncmike@xxxxxxxxxx>
Date: Mon, 3 Dec 2007 12:59:19 -0500
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 03 Dec 2007 10:00:33 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <2C78DE77-3965-4681-84D6-AD61D783D2AC@xxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: IBM Linux Technology Center
References: <20071129201959.GC12559@xxxxxxxxxxxxxxxxxxxxxx> <06274E9C-E1CB-4C75-BEE5-F48960A1F989@xxxxxxxxxxxxxx> <2C78DE77-3965-4681-84D6-AD61D783D2AC@xxxxxxxxxxxxxx>
Reply-to: ncmike@xxxxxxxxxx
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.15+20070412 (2007-04-11)
On 03/12/07 10:37 -0500, Chris wrote:
Mike,

My reading of your scheduling groups implementation is that it induces hierarchal relationships (master/slave) between domains. That is, every group has one master and the rest are slaves. Although that implementation has the advantage of being small, the fixed relationship puts implicit limits on the organization of domains and the operations that can be applied to them.

Hi Chris,

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.

In addition to scheduling, I believe domain groups are applicable to other areas such as domain disaggregation, convenient migration, efficient security policy, etc.. As such, a non-hierarchical group mechanism is desirable.

The scheduling group is only visible to the credit scheduler, and
there is no meaning outside of the scheduler's process accounting. I
didn't want to modify the Domain structures, and it wasn't necessary
to get the desired scheduling behavior. I think other types of groups
may be useful, and it would be great to see your patches again.

Mike

--
Mike D. Day
IBM LTC
Cell: 919 412-3900
Sametime: ncmike@xxxxxxxxxx AIM: ncmikeday  Yahoo: ultra.runner
PGP key: http://www.ncultra.org/ncmike/pubkey.asc

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

<Prev in Thread] Current Thread [Next in Thread>