From mboxrd@z Thu Jan 1 00:00:00 1970 From: NISHIGUCHI Naoki Subject: Re: [RFC][PATCH] scheduler: credit scheduler for client virtualization Date: Thu, 04 Dec 2008 16:51:50 +0900 Message-ID: <49378C16.1040106@jp.fujitsu.com> References: <49364960.2060101@jp.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Return-path: 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: George Dunlap , xen-devel@lists.xensource.com Cc: Ian.Pratt@eu.citrix.com, disheng.su@intel.com, Keir Fraser List-Id: xen-devel@lists.xenproject.org Thank you for your suggestions. George Dunlap wrote: > On Wed, Dec 3, 2008 at 9:16 AM, Keir Fraser = wrote: >> Don't hack it into the existing sched_credit.c unless you are really s= haring >> significant amounts of stuff (which it looks like you aren't?). >> sched_bcredit.c would be a cleaner name if there's no sharing. Is a ne= w >> scheduler necessary -- could the existing credit scheduler be generali= sed >> with your boost mechanism to be suitable for both client and server? >=20 > I think we ought to be able to work this out; the functionality > doesn't sound that different, and as you say, keeping two schedulers > around is only an invitation to bitrot. I had thought that the scheduler for client would be needed separately=20 because this modification would influence a server workload. In order to=20 minimize modifications, the bcredit scheduler was implemented by=20 wrapping the current credit scheduler. I added the differences between=20 original and bcredit. But as a result, almost functions were created newl= y. Now, I agree that one scheduler is best. > The more accurate credit scheduling and vcpu credit "balancing" seem > like good ideas. For the other changes, it's probably worth measuring > on a battery of tests to see what kinds of effects we get, especially > on network throughput. I didn=92t think about the battery and the performance. > Nishiguchi-san, (I hope that's right!) as I understood from your > presentation, you haven't tested this on a server workload, but you > predict that the "boost" scheduling of 2ms will cause unnecessary > overhead for server workloads. Is that correct? Yes, you are correct. I answered that in Q/A. > Couldn't we avoid the overhead this way: If a vcpu has 5 or more > "boost" credits, we simply set the next-timer to 10ms. If the vcpu > yields before then, we subtract the amount of "boost" credits actually > used. If not, we subtract 5. That way we're not interrupting any > more frequently than we were before. I set the next-timer to 2ms in any vcpu having =93boost=94 credits since=20 every vcpu having =93boost=94 credits need to be run equally at short=20 intervals. If there are vcpus having =93boost=94 credits and the next-tim= er=20 of a vcpu is set to 10ms, the other vcpus will be waited during 10ms. At present, I am thinking that if the other vcpus don=92t have =93boost=94= =20 credits then we may set the next-timer to 30ms. > Come to think of it: won't the effect of setting the 'boost' time to > 2ms be basically counteracted by giving domains boost credits? I > thought the purpose reducing the boost time was to allow other domains > to run more quickly? But if a domain has more than 5 'boost' credits, > it will run for a full 10 ms anyway. Is that not so? I suppose that there are two domains given =93boost=94 credits. One domai= n=20 runs for 2ms, then the other domain runs for 2ms, then one domain runs=20 for 2ms, then the other domain runs for 2ms, =85 Because I think to need=20 that waited time of both is same. > Could you test your video latency measurement with all the other > optimizations, but with the "boost" time set to 10ms instead of 2? If > it works well, it's probably worth simply merging the bulk of your > changes in and testing with server workloads. I tested the video latency measurement with the =93boost=94 time set to=20 10ms. But it regretted not to work well. As I was mentioned above, the=20 vcpu was occasionally waited during 10ms. On my patch, =93boost=94 time is tuneable. How about the default =93boost= =94=20 time is 30ms and if necessary, =93boost=94 time is set? Is it acceptable? In order to lengthen the =93boost=94 time as much as possible, I will thi= nk=20 about computing the length of the next-timer of the vcpu having =93boost=94= =20 credits. I=92ll try to revise the patch. And thanks again. Best regards, Naoki Nishiguchi