From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53635) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzqQN-000287-5f for qemu-devel@nongnu.org; Tue, 21 Feb 2012 09:10:41 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RzqQG-0007Iq-Tw for qemu-devel@nongnu.org; Tue, 21 Feb 2012 09:10:35 -0500 Received: from ssl.dlh.net ([91.198.192.8]:34632) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzqQG-0007Id-J3 for qemu-devel@nongnu.org; Tue, 21 Feb 2012 09:10:28 -0500 Message-ID: <4F43A5CE.4080306@dlh.net> Date: Tue, 21 Feb 2012 15:10:22 +0100 From: Peter Lieven MIME-Version: 1.0 References: <652e3025-0341-4d2c-b40f-212fd4c63eb7@zmail09.collab.prod.int.phx2.redhat.com> In-Reply-To: <652e3025-0341-4d2c-b40f-212fd4c63eb7@zmail09.collab.prod.int.phx2.redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] win7 bad i/o performance, high insn_emulation and exists List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vadim Rozenfeld Cc: Gleb Natapov , qemu-devel@nongnu.org, kvm@vger.kernel.org On 21.02.2012 14:56, Vadim Rozenfeld wrote: > > ----- Original Message ----- > From: "Peter Lieven" > To: "Gleb Natapov" > Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org, vrozenfe@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 su= re >>>>>>>> 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? > unfortunately not. i found the following in an old knowledge base article=20 (http://support.microsoft.com/kb/938448): "Only Windows Server 2003 with Service Pack 2 uniprocessor ACPI HALs use=20 *PMTIMER* for QPC by default. Multiprocessor ACPI HALs will use=20 *PMTIMER* only if *USE_PLATFORM_CLOCK *flag is set by the BIOS or if the=20 */usepmtimer *boot.ini option is used. Other HAL types don=E2=80=99t supp= ort=20 *PMTIMER* and will use *TSC* by default for QPC By default, Windows Server 2003 Service Pack 2 (SP2) uses the PM timer=20 for all Advanced Configuration and Power Interface (ACPI) HALs unless=20 one of the following conditions aretrue: * The check process to determine whether the BIOS supports the APIC or ACPI HALs fails. * * Note:* If the BIOS does not support the ACPI HAL, contact the original equipment manufacturer to determine whether a BIOS update is available that will resolve the problem. If a BIOS update is not available, you must use the PM timer by using the */usepmtimer* switch. If you are not running Windows Server 2003 SP2, you must force the AMD=20 computer to use the PM timer by using the */usepmtimer* switch. *Note* The decision to use the PM timer or the TSC timer is made during=20 a check that is performed at startup to query the BIOS and to determine=20 whether the BIOS will support the PM timer functions. This check is not=20 completely accurate on AMD chipsets. Therefore, you must use the=20 */usepmtimer* switch. In Windows Server 2003 SP2, this section of code was rewritten.=20 Therefore, the correct performance monitor data appears on AMD chipsets=20 that have Windows Server 2003 SP2 installed, and you do not have to use=20 the */usepmtimer* switch. For more information about ACPI and APCI hardware support, click the=20 following article number to view the article in the Microsoft Knowledge=20 Base: 309283 HAL options after=20 Windows XP or Windows Server 2003 Setup The third-party products that this article discusses are manufactured by=20 companies that are independent of Microsoft. Microsoft makes no=20 warranty, implied or otherwise, about the performance or reliability of=20 these products." - so it seems windows prefers pmtimer over tsc. has anyone an idea/hack to=20 make the acpi_pm timer fail without disabling acpi completely? thanks, peter