From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FgI1t-0005C2-G1 for qemu-devel@nongnu.org; Wed, 17 May 2006 05:09:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FgI1r-0005Bl-Vk for qemu-devel@nongnu.org; Wed, 17 May 2006 05:09:16 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FgI1r-0005Bi-Qk for qemu-devel@nongnu.org; Wed, 17 May 2006 05:09:15 -0400 Received: from [24.93.47.44] (helo=ms-smtp-05.texas.rr.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FgI4h-0008MV-6m for qemu-devel@nongnu.org; Wed, 17 May 2006 05:12:11 -0400 Received: from [192.168.0.11] (cpe-67-9-160-120.austin.res.rr.com [67.9.160.120]) by ms-smtp-05.texas.rr.com (8.13.6/8.13.6) with ESMTP id k4H99EYC029244 for ; Wed, 17 May 2006 04:09:14 -0500 (CDT) Message-ID: <446AE833.8010507@austin.rr.com> Date: Wed, 17 May 2006 04:09:07 -0500 From: Lonnie Mendez MIME-Version: 1.0 Subject: Re: [Qemu-devel] objective benchmark? References: <200605152203.00826.mr@ramendik.ru> <44695113.8040708@us.ibm.com> <000e01c678b3$cd372460$0464a8c0@athlon> <4469BC04.1080809@austin.rr.com> <005301c67982$e8ea81f0$0464a8c0@athlon> In-Reply-To: <005301c67982$e8ea81f0$0464a8c0@athlon> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Kazu wrote: >Here is values of ticks_per_sec on Athlon 64 3000+ . >i686 host: >1790803394 >1790784284 >1790774719 >1790798849 >1790814225 > >x86_64 host: >1790764763 >1790815837 >1790816089 >1790803590 >1790771017 > > Those are some very sane values. >I attached a patch that I modifed from your patch. It can be applied by >patch -p0. I checked it works for Athlon 64 with cpuspeed service (Power >Now!). ticks_per_sec changed dynamically but a clock of win2k guest on >x86_64 Linux host works fine. > >If your guest OS is Linux, it is necessary to set clock=pit at guest OS'es >startup. TSC may change. > >I hope it works for SpeedStep. > >I can't test i686 Linux host because ACPI and cpuspeed doesn't work on my >PC. > >I think it is better to detect CPU change signal and calibrate >ticks_per_sec. > That sounds like a good idea. The kernel probably has some interface to monitor for this. Here is some output from said attached patch: ticks_per_sec set as 210734086 ticks_per_sec set as 204415638 ticks_per_sec set as 255738952 ticks_per_sec set as 105989831 ticks_per_sec set as 1113215464 ticks_per_sec set as 1126700925 ticks_per_sec set as 1126291452 ticks_per_sec set as 1127055498 ticks_per_sec set as 1127255910 ticks_per_sec set as 1127059553 ticks_per_sec set as 1126568251 ticks_per_sec set as 43726804 ticks_per_sec set as 254415811 ticks_per_sec set as 210672485 ticks_per_sec set as 203385010 ticks_per_sec set as 97492292 ticks_per_sec set as 404263903 ticks_per_sec set as 306991778 iirc, this is an intel bug. It is supposedly corrected for in newer processors but there are soo many affected ones out there already. I can't imagine the amd processors also suffer such a poor design flaw like this and apparently report sane values for rdtsc with their frequency scaling technology. Disabling ACPI support on the host seems to make everything work, but you lose power management and other features which is no good for a laptop. "Pentium M, and particular models of P4 and Xeon, processors with SpeedStep enabled also exhibit this problem - the TSC register increments once per core clock cycle. If the clock rate is reduced the rate at which TSC increments will also be reduced. Newer models of Pentium 4 and Xeon tick at a constant rate regardless of the current core clock rate."