[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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |