From mboxrd@z Thu Jan 1 00:00:00 1970 From: "David S. Ahern" Subject: Re: performance with guests running 2.4 kernels (specifically RHEL3) Date: Fri, 16 May 2008 22:31:24 -0600 Message-ID: <482E5F9C.6000207@cisco.com> References: <48054518.3000104@cisco.com> <4805BCF1.6040605@qumranet.com> <4807BD53.6020304@cisco.com> <48085485.3090205@qumranet.com> <480C188F.3020101@cisco.com> <480C5C39.4040300@qumranet.com> <480E492B.3060500@cisco.com> <480EEDA0.3080209@qumranet.com> <480F546C.2030608@cisco.com> <481215DE.3000302@cisco.com> <20080428181550.GA3965@dmt> <4816617F.3080403@cisco.com> <4817F30C.6050308@cisco.com> <48184228.2020701@qumranet.com> <481876A9.1010806@cisco.com> <48187903.2070409@qumranet.com> <4826E744.1080107@qumranet.com> <4826F668.6030305@qumranet.com> <48290FC2.4070505@cisco.com> <48294272.5020801@qumranet.com> <482B4D29.7010202@cisco.com> <482C1633.5070302@qumranet.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------010503050202050902010608" Cc: kvm-devel To: Avi Kivity Return-path: In-Reply-To: <482C1633.5070302@qumranet.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: kvm-devel-bounces@lists.sourceforge.net Errors-To: kvm-devel-bounces@lists.sourceforge.net List-Id: kvm.vger.kernel.org This is a multi-part message in MIME format. --------------010503050202050902010608 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Avi Kivity wrote: > > Okay, I committed the patch without the flood count == 5. > I've continued testing the RHEL3 guests with the flood count at 3, and I am right back to where I started. With the patch and the flood count at 3, I had 2 runs totaling around 24 hours that looked really good. Now, I am back to square one. I guess the short of it is that I am not sure if the patch resolves this issue or not. If you want to back it out, I can continue to apply on my end as I continue testing. A snapshot of kvm_stat -f 'mmu*' -l is attached for two test runs with the patch (line wrap is horrible inline). I will work on creating an ap that will stimulate kscand activity similar to what I am seeing. Also, in a prior e-mail I mentioned guest time advancing rapidly. I've noticed that with the -no-kvm-pit option the guest time is much better and typically stays within 3 seconds or so of the host, even through the high kscand activity which is one instance of when I've noticed time jumps with the kernel pit. Yes, this result has been repeatable through 6 or so runs. :-) david --------------010503050202050902010608 Content-Type: text/plain; name="kvm-stats-rhel3" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="kvm-stats-rhel3" kvm-68 with Avi's patch and flood threshold at 3: mmio_exit mmu_cache mmu_flood mmu_pde_z mmu_pte_u mmu_pte_w mmu_recyc mmu_shado 175 880 880 0 1832 2714 0 880 35 868 868 0 1782 2650 0 868 91 8522 8520 131 29179 38651 0 8722 28 991 992 0 2314 3312 0 992 91 796 796 0 1648 2445 0 796 81 1944 1943 0 7241 9213 0 1943 98 4149 4148 31 11975 16196 0 4214 41 3379 3380 0 9710 13100 0 3378 42 17729 17730 0 48415 66152 0 17729 guest has an apparent lockup at this point and when it unfreezes kscand cpu time jumps on the order of the time command line response was frozen (on the order of 30 seconds or more) 14 18634 18633 0 48286 66921 0 18634 21 18607 18607 0 48395 67001 0 18607 91 17991 17991 0 50039 68040 0 17991 7 17919 17920 0 53731 71650 0 17919 7 18060 18060 0 53539 71599 0 18060 21 17755 17755 0 52714 70469 0 17755 ----------------------- with Avi's patch and flood threshold at 5. mmio_exit mmu_cache mmu_flood mmu_pde_z mmu_pte_u mmu_pte_w mmu_recyc mmu_shado 147 604 602 42 21299 21957 0 660 112 163 167 23 7567 7759 0 170 105 0 1 2 3378 3381 0 1 14 4 4 0 9685 9689 0 4 137 628 623 43 21557 22255 0 682 42 0 2 4 5834 5840 0 2 91 14 16 0 25741 25757 0 16 28 58 55 0 23571 23626 0 55 84 627 624 45 32588 33268 0 685 132 9 13 1 12162 12177 0 13 91 0 1 0 3422 3423 0 1 35 1 1 0 4624 4625 0 1 102 237 244 0 12257 12504 0 242 19 401 387 46 20643 21088 0 449 26 3 4 1 127252 127261 0 4 guest has an apparent lockup at this point and when it unfreezes kscand cpu time jumps on the order of the time command line response was frozen (on the order of 30 seconds or more) 21 0 0 0 182651 182651 0 0 14 0 0 0 182524 182523 0 0 178 4 5 4 170752 170759 0 5 35 0 0 0 181471 181473 0 0 21 0 0 0 182263 182263 0 0 14 0 0 0 182493 182494 0 0 21 0 0 0 182489 182488 0 0 91 0 0 0 182203 182204 0 0 35 0 0 0 182378 182377 0 0 --------------010503050202050902010608 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ --------------010503050202050902010608 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel --------------010503050202050902010608--