Bug#634149: kvm extremely __slow__ under 2.6.39-2-amd64 compared to 2.6.32-5-amd64
reassign 634149 src:linux-2.6 tags 634149 - moreinfo + confirmed merge 633589 634149 thanks 18.07.2011 14:24, Michael Tokarev wrote: [..] So, the problem is that with this kernel commit: commit 7972995b0c346de76fe260ce0fd6bcc8ffab724a Author: Gleb Natapov g...@redhat.com Date: Thu Mar 18 15:20:24 2010 +0200 KVM: x86 emulator: Move string pio emulation into emulator.c Currently emulation is done outside of emulator so things like doing ins/outs to/from mmio are broken it also makes it hard (if not impossible) to implement single stepping in the future. The implementation in this patch is not efficient since it exits to userspace for each IO while previous implementation did 'ins' in batches. Further patch that implements pio in string read ahead address this problem. Signed-off-by: Gleb Natapov g...@redhat.com Signed-off-by: Marcelo Tosatti mtosa...@redhat.com which went into mainline with 2.6.35, there has been quite some changes in PIO emulation handling in kvm which resulted in correct but slow (as opposed by fast but incorrect) emulation. This slowed down guests that use PIO to access disks. Among these are WinXP (it switches from DMA to PIO after some I/O errors), WinNT (ditto) and - apparently - Hurd. Someone needs to investigate why Hurd does not use DMA in this case - PIO is long obsolete technology. I'd mark this as notabug (not possible with BTS) or wontfix, but it's definitely possible to optimize the new code further to speed things up. If it's worth the effort is another question. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634149: kvm extremely __slow__ under 2.6.39-2-amd64 compared to 2.6.32-5-amd64
severity 634149 wishlist quit Hi, Michael Tokarev wrote: So, the problem is that with this kernel commit: commit 7972995b0c346de76fe260ce0fd6bcc8ffab724a Author: Gleb Natapov g...@redhat.com Date: Thu Mar 18 15:20:24 2010 +0200 KVM: x86 emulator: Move string pio emulation into emulator.c [...] which went into mainline with 2.6.35, there has been quite some changes in PIO emulation handling in kvm which resulted in correct but slow (as opposed by fast but incorrect) emulation. This slowed down guests that use PIO to access disks. Among these are WinXP (it switches from DMA to PIO after some I/O errors), WinNT (ditto) and - apparently - Hurd. Thanks for a nice explanation. [...] I'd mark this as notabug (not possible with BTS) or wontfix, but it's definitely possible to optimize the new code further to speed things up. If it's worth the effort is another question. That means wishlist, and probably not worth tracking unless we want to document it somewhere or someone is interested in working on it, right? Svante, if I were in your shoes, I'd come up with some words of warning for a qemu-performance.txt file and send them (ideally as a patch against the qemu or qemu-kvm package) to k...@vger.kernel.org, cc-ing this bug. And if you are looking for a low-level Hurd coding project, perhaps look into teaching the Hurd some performance tricks --- it would help on raw hardware, too. :) Investigating how to improve kvm's PIO emulation might also be interesting. Hope that helps, Jonathan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634149: kvm extremely __slow__ under 2.6.39-2-amd64 compared to 2.6.32-5-amd64
Jonathan Nieder wrote: Michael Tokarev wrote: So, the problem is that with this kernel commit: commit 7972995b0c346de76fe260ce0fd6bcc8ffab724a Author: Gleb Natapov g...@redhat.com Date: Thu Mar 18 15:20:24 2010 +0200 KVM: x86 emulator: Move string pio emulation into emulator.c [...] which went into mainline with 2.6.35, there has been quite some changes in PIO emulation handling in kvm which resulted in correct but slow (as opposed by fast but incorrect) emulation. This slowed down guests that use PIO to access disks. [...] That means wishlist, and probably not worth tracking unless we want to document it somewhere or someone is interested in working on it, right? On second thought, a regression's a regression --- going from usable but subtly buggy to unusable is not progress. :) Maybe it would be possible to introduce some kind of parameter to get back the speed at the cost of correctness again? Just musing. Sorry for the noise; I'll leave this to the experts. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634149: kvm extremely __slow__ under 2.6.39-2-amd64 compared to 2.6.32-5-amd64
tags 634149 + moreinfo thanks There's almost no information in this bugreport. You never specified which command line options did you use. You never stated what kind of guest is that, ie, what one should do to reproduce this. You didn't tell us what kind of storage do you have. One more note: you cloned this bugreport to qemu-kvm package, even if that package appears to be unaffected (since the same version works differently with different kernels). Why? Please provide some information to reproduce the problem. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634149: kvm extremely __slow__ under 2.6.39-2-amd64 compared to 2.6.32-5-amd64
On Mon, 2011-07-18 at 11:03 +0400, Michael Tokarev wrote: tags 634149 + moreinfo thanks There's almost no information in this bugreport. You never specified which command line options did you use. You never stated what kind of guest is that, ie, what one should do to reproduce this. You didn't tell us what kind of storage do you have. Host: Linux AMD + Intel Guest: GNU/Hurd sysbench numbers: From the AMD box. see below for more information. One more note: you cloned this bugreport to qemu-kvm package, even if that package appears to be unaffected (since the same version works differently with different kernels). Why? Maybe that was a mistake. Somebody on #kvm mentioned that later Linux kernels opens up more features, that kvm uses. Unfortunately these features are not HW-accelerated. Please provide some information to reproduce the problem. Commandline: (both Intel and AMD boxes) kvm -m 1024 -net nic,model=rtl8139 -net user,hostfwd=tcp::5556-:22 -drive cache=writeback,index=0,media=disk,file=hurd.img -cdrom netinst.iso Intel box: == RAM: 4GB lscpu Architecture: x86_64 CPU op-mode(s):32-bit, 64-bit CPU(s):4 Thread(s) per core:1 Core(s) per socket:4 CPU socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family:6 Model: 15 Stepping: 11 CPU MHz: 1596.000 Virtualization:VT-x L1d cache: 32K L1i cache: 32K L2 cache: 4096K cat /proc/cpuinfo + 3 more CPUs processor : 0 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz stepping: 11 cpu MHz : 2400.000 cache size : 4096 KB physical id : 0 siblings: 4 core id : 0 cpu cores : 4 apicid : 0 initial apicid : 0 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm lahf_lm tpr_shadow vnmi flexpriority bogomips: 4800.16 clflush size: 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: Loaded modules: kvm_intel 38146 6 kvm 214248 1 kvm_intel Storage: [1.112138] scsi 0:0:0:0: Direct-Access ATA ST3500630AS 3.CH PQ: 0 ANSI: 5 [1.123907] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB) [1.123966] sd 0:0:0:0: [sda] Write Protect is off [1.123968] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [1.123988] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA AMD-box: (that box is shut down right now, more info abut the box can be found in bug #619034.) RAM: 2GB CPU: [ 186.838814] kvm: Nested Virtualization enabled [ 188.350222] powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ (2 cpu cores) (version 2.20.00) Board info: sys_vendor: MICRO-STAR INTERNATIONAL CO., LTD product_name: MS-7253 product_version: 1.0 chassis_vendor: MICRO-STAR INTERNATIONAL CO., LTD chassis_version: bios_vendor: Phoenix Technologies, LTD bios_version: V1.6 board_vendor: MICRO-STAR INTERNATIONAL CO., LTD board_name: MS-7253 board_version: 1.0 Loaded modules: kvm_amd42175 0 kvm 255441 1 kvm_amd Storage: Similar as the Intel box, 500GB SATA -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#634149: kvm extremely __slow__ under 2.6.39-2-amd64 compared to 2.6.32-5-amd64
18.07.2011 11:45, Svante Signell wrote: On Mon, 2011-07-18 at 11:03 +0400, Michael Tokarev wrote: [] kvm -m 1024 -net nic,model=rtl8139 -net user,hostfwd=tcp::5556-:22 -drive cache=writeback,index=0,media=disk,file=hurd.img -cdrom netinst.iso Ok. What's hurd.img and what's netinst.iso? How did you install whatever is in hurd.img? The thing is: I need information to reproduce the issue. If I'll use the above command line locally it will complain for sure -- complain about missing hurd.img and netinst.iso, because I don't have these here, so I need a way to get/create them. For the rest, that's basically ok. Only missing info is the guest bits. btw, it was me with whom you spoke in #kvm. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
