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
|
Home