Re: [Qemu-devel] win7 bad i/o performance, high insn_emulation and exists

[Vadim Rozenfeld]

----- Original Message -----
From: "Peter Lieven" <address@hidden>
To: "Gleb Natapov" <address@hidden>
Cc: address@hidden, address@hidden, address@hidden
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.