From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Subject: Re: Is guest OS oriented scheduling welcome? Date: Wed, 22 Apr 2009 15:22:54 +0300 Message-ID: <49EF0C1E.2060203@redhat.com> References: <1060494.867561240402736300.JavaMail.coremail@app167.163.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: kvm@vger.kernel.org, anthony@codemonkey.ws To: =?UTF-8?B?5YiY5b+X5bu6?= Return-path: Received: from mx2.redhat.com ([66.187.237.31]:38949 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750830AbZDVMXG (ORCPT ); Wed, 22 Apr 2009 08:23:06 -0400 In-Reply-To: <1060494.867561240402736300.JavaMail.coremail@app167.163.com> Sender: kvm-owner@vger.kernel.org List-ID: =E5=88=98=E5=BF=97=E5=BB=BA wrote: > Hello folks, > In the past, it was said KVM would like to treat the guest OS threads= differently in scheduling. However, till now, the qemu thread is regar= ded as a conventional user thread. Therefore, it is hard to control how= much CPU slices one guest OS can utilize. I don't think a computing cl= oud provider likes this idea. > And, what's more, "Xen and Co.: Communication-aware CPU Scheduling fo= r Consolidated Xen-based Hosting Platforms"(http://www.cse.psu.edu/~sgo= vinda/papers/vee07.pdf) has shown that the standard thread scheduling i= n Linux might not fit the virtualization environment well. > I have ported Xen's credit scheduler to KVM. Do you mean, to KVM, or to the Linux scheduler? > With my work, the users can control how much CPU a guest OS can occu= py. > The principles are: > 1. all the vcpu threads are declared as FIFO RealTime threads; > 2. before a vcpu thread enters guest mode, its blackboard is checked = first, to see if the scheduler wants it to continue. If the vcpu thread= has a bad luck, it will give up cpu and waits for permission. > 3. there is a per-cpu scheduler, which is triggered periodically by i= ts timer. The scheduler writes the scheduling results to the interested= party's blackboards. To those that get the permission, the scheduler w= ill try to wake them up in case of their sleeping.=20 > 4. In order to port Xen's scheduler, the host Linux is treated as a v= irtual machine too. However, it never checks its blackboard. > 5. a user level per-VM credit control mechanism is implemented, to al= low users to dynamically adjust a virtual machine's CPU quota. > Although a vcpu might continue to run for a while after the scheduler= has decided that it should actually yield the cpu, our experiments sho= w that this brings trival influence. > The interaction-oriented scheduling are going to be ported/developed. > > If KVM welcomes this function, I will post it out. > I think this is very interesting, but should be integrated with the=20 Linux scheduler, so it could apply to normal processes, and so it can=20 account for host mode, not just guest mode. --=20 error compiling committee.c: too many arguments to function