[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH] Accurate vcpu weighting for credit scheduler



Hi, Emmanuel

1)rounding error for credit

This patch is over rounding error.
So I think it does not need to consider this effect.
If you think, would you suggest me your patch.
It seems changing CSCHED_TICKS_PER_ACCT is not enough.

2)Effect for I/O intensive job.

I am not change the code for BOOST priority.
I just changes "credit reset" condition.
It should be no effect on I/O intensive(but I am not measured it.)
If it needs, I will test it.
Which test is best for this change?
(Simple I/O test is not enough for this case, 
I think complex domain I/O configuration is needed to prove this patch effect.)

3)vcpu allocation measurement.

At first time, I use
  http://weather.ou.edu/~apw/projects/stress/
  stress --cpu xx --timeout xx --verbose
then I use simple test.(since 2vcpus on 1domain)
  yes > /dev/null &
  yes > /dev/null & 
Now I test with suggested method, then result is
     original   w/ patch
dom1    27        25
dom2    27        25
dom3    53        50
dom4    91        98


Thanks
Atsushi SAKAI




Emmanuel Ackaouy <ackaouy@xxxxxxxxx> wrote:

> On Dec 9, 2008, at 2:25, George Dunlap wrote:
> > On Tue, Dec 9, 2008 at 7:33 AM, Atsushi SAKAI  
> > <sakaia@xxxxxxxxxxxxxx> wrote:
> >> You mean it should get rid of "credit reset"?
> >
> > Yes, that's exactly what I was thinking.  Removing the check for vcpus
> > on the runqueue may actually be functionally equivalent to removing
> > the check altogether.
> 
> Essentially, this code is there as a safeguard against rounding errors
> and other oddball cases. In theory, a runnable VCPU should seldom
> accumulate more than one time slice's worth of credits.
> 
> The problem with your change is that a VCPU that is not a spinner
> but instead runs and sleeps may not be removed from the accounting
> list because when it should because it will not always be running when
> accounting and the check in question is performed. Potentially this will
> do very bad things for VCPUs that are I/O intensive or otherwise yield
> or sleep for a short time before consuming a full time slice.
> 
> One thing that may help here is to make the credit calculations less
> prone to rounding errors. One thing I had wanted to do while at
> XenSource but never got around to was to change the arithmetic
> so that instead of 30 credits representing a time slice, we would
> make this a much bigger number.
> 
> In this case for example, you would get credit allocations that had
> less significant rounding errors if you used 30000 instead of 30
> credits per time slice:
> 
> dom1 vcpu0,1 w128 credit 3750
> dom2 vcpu0,1 w128 credit 3750
> dom3 vcpu0,1 w256 credit 7500
> dom4 vcpu0,1 w512 credit 15000
> 
> I suspect this would get rid of a large number of cases such as the
> one you are reporting, where a runnable VCPU's credit exceeds
> one entire time slice. This type of change would improve accuracy
> and not screw up credit computation for I/O intensive and other
> non spinning domains.
> 
> What do you think?
> 
> Also please confirm that your VCPUs are indeed doing simple
> "while(1);" loops.
> 
> Cheers,
> Emmanuel.



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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.