From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Lieven Subject: Re: performance trouble Date: Thu, 22 Mar 2012 08:57:08 +0100 Message-ID: <4F6ADB54.9050207@dlh.net> References: <20120222163356.GE26955@nfs-rbx.ovh.net> <20120223083807.GA17505@redhat.com> <20120316101331.GM12293@nfs-rbx.ovh.net> <20120319105134.GA27928@redhat.com> <20120320093220.GS12293@nfs-rbx.ovh.net> <20120320094541.GH22368@redhat.com> <20120320111839.GT12293@nfs-rbx.ovh.net> <20120320123821.GL22368@redhat.com> <20120321111001.GV12293@nfs-rbx.ovh.net> <4F6A1056.1020904@dlh.net> <20120322075345.GA22368@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: David Cure , Avi Kivity , kvm@vger.kernel.org, Vadim Rozenfeld To: Gleb Natapov Return-path: Received: from ssl.dlh.net ([91.198.192.8]:47285 "EHLO ssl.dlh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751144Ab2CVH5K (ORCPT ); Thu, 22 Mar 2012 03:57:10 -0400 In-Reply-To: <20120322075345.GA22368@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On 22.03.2012 08:53, Gleb Natapov wrote: > On Wed, Mar 21, 2012 at 06:31:02PM +0100, Peter Lieven wrote: >> On 21.03.2012 12:10, David Cure wrote: >>> hello, >>> >>> Le Tue, Mar 20, 2012 at 02:38:22PM +0200, Gleb Natapov ecrivait : >>>> Try to add to cpu >>>> definition in XML and check command line. >>> ok I try this but I can't use to map the host cpu >>> (my libvirt is 0.9.8) so I use : >>> >>> >>> Opteron_G3 >>> >>> >>> >>> (the physical server use Opteron CPU). >>> >>> The log is here : >>> http://www.roullier.net/Report/report-3.2-vhost-net-1vcpu-cpu.txt.gz >>> >>> And now with only 1 vcpu, the response time is 8.5s, great >>> improvment. We keep this configuration for production : we check the >>> response time when some other users are connected. >> please keep in mind, that setting -hypervisor, disabling hpet and >> only one vcpu >> makes windows use tsc as clocksource. you have to make sure, that your vm >> is not switching between physical sockets on your system and that you have >> constant_tsc feature to have a stable tsc between the cores in the >> same socket. its also likely that the vm will crash when live migrated. >> > All true. I asked to try -hypervisor only to verify where we loose > performance. Since you get good result with it frequent access to PM > timer is probably the reason. I do not recommend using -hypervisor for > production! > >> @gleb: do you know whats the state of in-kernel hyper-v timers? >> > Vadim is working on it. I'll let him answer. @avi, gleb: another option would be to revisit the old in-kernel pm-timer implementation and check if its feasible to use this as an alternative. it would also help non hyper-v aware systems (i think bsd and old windows like xp). i rebased this old implementation and can confirm that it does also solve the performance slow down. peter >> peter >> >>> David. >>> -- >>> 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 > -- > Gleb.