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

Re: [Xen-devel] Re: credit scheduler: the policy of credit assignment

To: Hirokazu Takahashi <taka@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] Re: credit scheduler: the policy of credit assignment
From: Emmanuel Ackaouy <ack@xxxxxxxxxxxxx>
Date: Thu, 6 Jul 2006 10:28:17 +0100
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 06 Jul 2006 02:28:38 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060706.085441.41627071.taka@xxxxxxxxxxxxx>
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>
Mail-followup-to: Hirokazu Takahashi <taka@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
References: <20060705.132350.66157177.taka@xxxxxxxxxxxxx> <20060705101042.GA12087@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <20060706.085441.41627071.taka@xxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.4.1i
On Thu, Jul 06, 2006 at 08:54:41AM +0900, Hirokazu Takahashi wrote:
> > Credit_balance only comes into play when active domains with positive
> > credit go idle. It's a mechanism to converge the system towards its
> > stable state.
> 
> Yes, I think I understand the intention.
> However, I don't think the mechanism is effective enough.
> 
> > Are you suggesting that credit_balance, as it is used, should be the
> > sum of credit *prior* to incrementing active domains' credits?
> 
> I think it would be better.
> 
> > I'm not really sure I understand what you're concerned about here.
> > Can you elaborate and use a specific example to illustrate?
> 
> 
> Please suppose the system has 1 cpu and the sum of the credit goes
> down to zero or quite small value unluckily.
> 
>            credit
> Domain A     20
> Domain B    -10        
> Domain C    -10

I don't understand why it is "unlucky" that the credit sum is
about zero?

> 30msec later, the domains consumed 30msec if they are cpu intensive
> domains. The credits may become:
> 
> Domain A     0
> Domain B    -15
> Domain C    -15

More likely, because time-slices are 30ms, it would be:

Domain A    -10
Domain B    -10        
Domain C    -10


> Then, the credit scheduler divides 30 msec and gives it to each domains.
> The credits may become:
> 
> Domain A     15
> Domain B    -5
> Domain C    -10

You're not incrementing credits equally here so I assume you
mean that the domains have different weights and should
therefore get a different amount of CPU time.

If the domains had equal weights, you'd end up with:

Domain A    0
Domain B    0
Domain C    0

> The sum of the credit keeps the same value.
> I think there will be a chance to optimize it.

I don't understand why you think it is bad to have a stable
active credit sum converging on zero. It's the intent of the
scheduler to hand out as many credits as are being consumed.

As a matter of fact, having some domains credit positive and
others negative is the mechanism by which priorities change
and domains with higher weight get more CPU time. If all
domains were credit positive, they'd get the exact same
amount of CPU.

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

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