From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dor Laor Subject: Re: Limit the CPU usage of KVM Date: Tue, 18 Aug 2009 13:07:47 +0300 Message-ID: <4A8A7D73.8080701@redhat.com> References: <797E8D15ABC7AC4DADF6DE8A5F7CD9B4063EBDE4@xmb-hkg-416.apac.cisco.com> <4A8905DE.7020000@redhat.com> <797E8D15ABC7AC4DADF6DE8A5F7CD9B4063EBEAE@xmb-hkg-416.apac.cisco.com> <4A89115B.6000909@redhat.com> <797E8D15ABC7AC4DADF6DE8A5F7CD9B4063EC2E6@xmb-hkg-416.apac.cisco.com> Reply-To: dlaor@redhat.com Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org To: "Yu Jiang (yujia)" Return-path: Received: from mx2.redhat.com ([66.187.237.31]:37336 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753746AbZHRKHq (ORCPT ); Tue, 18 Aug 2009 06:07:46 -0400 In-Reply-To: <797E8D15ABC7AC4DADF6DE8A5F7CD9B4063EC2E6@xmb-hkg-416.apac.cisco.com> Sender: kvm-owner@vger.kernel.org List-ID: On 08/18/2009 11:54 AM, Yu Jiang (yujia) wrote: > Thanks, Dor. > More question inline:-) > > > Best regards, > Yu > >> On 08/17/2009 11:04 AM, Yu Jiang (yujia) wrote: >>> Hi Dor, >>> >>> Thank you very much for your reply! >>> >>> Our kernel of host os was based on 2.6.18, so cgroup is not >> avaialbe >>> for us. And our Intel chip supports constant_tsc. >>> We will run RHEL 5.4 as guest os. Will the clock of guest >> os still be >>> a issue if we use kvm-clock in guest os? >> >> The first release of rhel5.4 guest won't support guest pv >> clock. It does support the host side of the clock. Further >> updates should enable this feature in the guest. > > So, the kvm-clock is not available for us. What do you mean about host > side of clock? What clocksource should be used for the first release of I meant that kvmclock does exist in the hypervisor/host side but not in the guest. > rhel5.4 as guest os. TSC? If we use TSC as clocksource, should we run > KVM with the -no-kvm-pit-reinjection flag? You need both the -no-kvm-pit-reinjection and add these guest kernel command line: rhel5.4 64 bit: divider=10 notsc lpj=n (n is the number that the host uses) rhel5.4 32bit: divider=10 clocksource=acpi_pm lpj=n > >> >>> And does it mean guest os will always has clock issue, if >> vcpu thread >>> was not scheduled on time? >> >> The stable tsc is good, but the problem is that it works in >> conjunction with the pit clock. The OS tries to compensate >> for lost ticks that it automatically identifies (also on real >> hardware). This is why we recommend to run RHEL guest with >> -no-kvm-pit-reinjection flag. >> My fear is that too large pauses will drive the OS crazy. >> You can test if it can cope with it. > > Since we are not able to avoid larger pause in virtual machine > envrionment on heavy load, hopefully it will not cause issue. > >> >> Why not use nice instead? The effect is similar, but it might >> be a bit more smooth. > > With nice, we are able to remove the lantency of application on host os. > But, our customer may become crazy if they found the CPU usage of host > reach 100%. If you fine the guests with positive nice, other applications won't be affected. > >> >>> >>> Thanks, >>> Yu >>> >>> >>> >>> >>> On 08/17/2009 08:09 AM, Yu Jiang (yujia) wrote: >>>> Hi KVM experts, >>>> >>>> Our user case needs to run KVM and application on host >> together. To >>>> reserve some CPU resource for application, we want to >> limit the CPU >>>> usage of KVM. Without KVM CPU usage limitation, the idle >> CPU of host >>>> OS becomes 0% in peak time. >>>> >>>> I have searched this topic on internet, but didn't find >> much comments. >>>> >>>> One possible solution could be managing KVM process as regular >>>> process >>> >>>> on host OS, and use tool like http://cpulimit.sourceforge.net/ to >>>> limit maximum CPU usage of VM. Basically, the cpulimit tool use >>>> SIGSTP >>> >>>> and SIGCONT signals to stop and resume the execution of >> KVM process. >>>> It works fine for us at moment. But, I feel there may be >> some risk to >>>> do this, because the signal will cause whole process of KVM >>>> paused(not >>> >>>> only vcpu thread). Do you think it's safe to use cpulimit kinds of >>>> tool to SIGSTP/SIGCONT kvm? >>>> >>>> Another possible solution was: >>>> Enhance QEMU user space to monitor the CPU usage of >> itself, and use >>>> existing way(pause_all_vcpus?) to pause vcpu thread of KVM in case >>>> KVM >>> >>>> reaches CPU usage limitation. Is this solution possible? >>> >>> A mgmt daemon can control qemu using the monitor and >> stop/cont it on >>> these cases. >>> >>> The main problem with the two solutions above is that the >> guest clock >>> might drift. Moreover, you increase the latency for the guest >>> OS/applications. >>> >>> You can use the 'nice' command to priorities the host applications. >>> For newer kernels you should use cgroups that solves this specific >>> issue exactly. >>> >>>> >>>> Any idea? >>>> >>>> >>>> Thanks, >>>> Yu >>>> >>>> -- >>>> To unsubscribe from this list: send the line "unsubscribe >> kvm" in the >>>> body of a message to majordomo@vger.kernel.org More >> majordomo info at >>> >>>> http://vger.kernel.org/majordomo-info.html >>> >> >> > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html