----- Original Message ----- From: "Peter Lieven" <p...@dlh.net> To: "Gleb Natapov" <g...@redhat.com> Cc: qemu-devel@nongnu.org, k...@vger.kernel.org, vroze...@redhat.com Sent: Tuesday, February 21, 2012 2:05:25 PM Subject: Re: win7 bad i/o performance, high insn_emulation and exists
On 21.02.2012 12:46, Gleb Natapov wrote: > On Tue, Feb 21, 2012 at 12:16:16PM +0100, Peter Lieven wrote: >> On 21.02.2012 12:00, Gleb Natapov wrote: >>> On Tue, Feb 21, 2012 at 11:59:23AM +0100, Peter Lieven wrote: >>>> On 21.02.2012 11:56, Gleb Natapov wrote: >>>>> On Tue, Feb 21, 2012 at 11:50:47AM +0100, Peter Lieven wrote: >>>>>>> I hope it will make Windows use TSC instead, but you can't be sure >>>>>>> about anything with Windows :( >>>>>> Whatever it does now it eates more CPU has almost equal >>>>>> number of exits and throughput is about the same (15MB/s). >>>>>> If pmtimer is at 0xb008 it still reads it like hell. >>>>>> >>>>>> I checked with bcedit /v that useplatformclock is set to "No". >>>>> Yeah, today I noticed that it is likely virtio drivers that hammer >>>>> on PM timer (at least rip of the instruction that access it is >>>>> very close to rip of the instruction that access virtio pio). >>>>> Vadim, Windows driver developer, is CCed. >>>> Ok, I will switch to IDE and e1000 to confirm this? Or does it not >>>> make sense? >>>> >>> It make perfect sense! Please try it. >> ~10MB/s. still a lot of 0xb008 reads. >> [VR] Could it be that you have Driver Verifier running in you system? > The same amount of reads essentially. So my theory is incorrect. Virtio > driver probably calls Windows function to do IO and the function > happens to be near the function that access PM timer. > > I wonder why time stamps in your traces are so coarse-grained. What do > you see in /sys/bus/clocksource/devices/clocksource0/current_clocksource ? its set to acpi_pm on the host. we changed that from tsc (choosen by kernel) after we encountered a kernel bug which ooops all hosts after approx. 270 days uptime. (https://lkml.org/lkml/2011/7/21/343). i am not sure if this is fixed in 2.6.38 or later kernels and we could go back to tsc. for testing i already checked this, but it doesn't give better performance. peter > -- > Gleb.
