From mboxrd@z Thu Jan 1 00:00:00 1970 From: Samuel Thibault Subject: Re: [0/3] DomGrp/SchedGrp Merge RFC Date: Wed, 6 Feb 2008 10:42:12 +0000 Message-ID: <20080206104212.GB4338@implementation.uk.xensource.com> References: <20080206102723.GA4338@implementation.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: Chris , "Mike D. Day" , xen-devel List-Id: xen-devel@lists.xenproject.org Keir Fraser, le Wed 06 Feb 2008 10:37:37 +0000, a écrit : > On 6/2/08 10:27, "Samuel Thibault" wrote: > > >> I'm driven by concrete use cases. Several of the upcoming uses you mention > >> need careful consideration of what they are useful for, to determine the > >> best way to design them into the system. Take resource sharing. Stub domains > >> sharing scheduler credits with the HVM guest is a rather special case, and > >> one where a master/slave relationship is not unreasonable (and hence in this > >> case I think it is arguable whether it is actually a good fit with domgrps > >> after all). > > > > Actually, in my former research team in Bordeaux, they would like to > > write a small domain that computes the scheduling of a bunch of others, > > for parallel scientific computing. > > Well that sounds plausible, but I'm not sure how resource pools or domgrps > would help with that. It sounds like a delegation mechanism (of privilege > and/or resource) would be more appropriate. Sure, delegation will be needed, but there needs to be a way to specify which domains that scheduler has control on. Samuel