From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FgRhO-0005ec-Sf for qemu-devel@nongnu.org; Wed, 17 May 2006 15:28:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FgRhN-0005eP-NI for qemu-devel@nongnu.org; Wed, 17 May 2006 15:28:45 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FgRhN-0005eM-HN for qemu-devel@nongnu.org; Wed, 17 May 2006 15:28:45 -0400 Received: from [84.96.92.60] (helo=Smtp.neuf.fr) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FgRkI-0003ez-UG for qemu-devel@nongnu.org; Wed, 17 May 2006 15:31:47 -0400 Received: from [86.73.70.129] by sp604001mt.gpm.neuf.ld (Sun Java System Messaging Server 6.2-5.05 (built Feb 16 2006)) with ESMTP id <0IZF00L9GCAZKWT0@sp604001mt.gpm.neuf.ld> for qemu-devel@nongnu.org; Wed, 17 May 2006 21:18:36 +0200 (CEST) Date: Wed, 17 May 2006 21:18:03 +0200 From: Fabrice Bellard Subject: Re: [Qemu-devel] objective benchmark? In-reply-to: <005301c67982$e8ea81f0$0464a8c0@athlon> Message-id: <446B76EB.6070201@bellard.org> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT References: <200605152203.00826.mr@ramendik.ru> <44695113.8040708@us.ibm.com> <000e01c678b3$cd372460$0464a8c0@athlon> <4469BC04.1080809@austin.rr.com> <005301c67982$e8ea81f0$0464a8c0@athlon> 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: > Tuesday, May 16, 2006 8:48 PM Lonnie Mendez wrote: > > >>Kazu wrote: >> >> >>>If you set /proc/sys/dev/rtc/max-user-freq to 1024 and disable cpuspeed >>>service that is related to SpeedStep/PowerNow! on a host OS, the clock in >>>guest OS works fine. >>> >>>I checked it on i686/x86_64 Linux host. >>> >> >> Mind saying how you checked this? I'm on a pentium-III mobile >>processor and the only way I've seen so far to make qemu + rdtsc behave >>100% is by disabling ACPI (boot with -noacpi). If I add a simple printf >>to cpu_calibrate_ticks it doesn't seem fixed to me: >> >>dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi >>-kernel-kqemu -soundhw es1370 >>ticks_per_sec set as 1126809000 >>dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi >>-kernel-kqemu -soundhw es1370 >>ticks_per_sec set as 17308857 >>dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi >>-kernel-kqemu -soundhw es1370 >>ticks_per_sec set as 103710852 >>dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi >>-kernel-kqemu -soundhw es1370 >>ticks_per_sec set as 15292604 >>dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi >>-kernel-kqemu -soundhw es1370 >>ticks_per_sec set as 96695295 >>dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi >>-kernel-kqemu -soundhw es1370 >>ticks_per_sec set as 1126761234 >>dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi >>-kernel-kqemu -soundhw es1370 >>ticks_per_sec set as 1126762522 >>dignome@vaio /prog/qemu-stuff $ qemu -localtime -hda winxp.img -no-acpi >>-kernel-kqemu -soundhw es1370 >>ticks_per_sec set as 49791263 >> >> The first entry is with the patch attached called >>'ticks_from_proc.patch' applied (I've been using this for almost a >>year). It sets the value ticks_per_sec, which happens to be used by a >>lot of qemu's hardware emulation, using information in /proc/cpuinfo. >>This doesn't fix the time issue as rdtsc is still used every time a >>SIGALRM signal occurs for timing, but at least the guest's emulated >>hardware runs to speed. >> >>dignome@vaio /prog/qemu-cvs/qemu-acpi/qemu $ find . -type f -exec fgrep >>-l 'ticks_per_sec' {} \; >>./audio/audio.c >>./audio/noaudio.c >>./audio/wavaudio.c >>./monitor.c >>./vl.c >>./vl.h >>./hw/acpi.c >>./hw/adlib.c >>./hw/arm_timer.c >>./hw/cuda.c >>./hw/fdc.c >>./hw/i8254.c >>./hw/i8259.c >>./hw/ide.c >>./hw/mc146818rtc.c >>./hw/mips_r4k.c >>./hw/ppc.c >>./hw/sb16.c >>./hw/sh7750.c >>./hw/slavio_timer.c >>./hw/usb-uhci.c >> >> The second patch adds the printf statement so you can see this for >>yourself. >> > > > 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 > > If I changed usleep(50 * 1000) to ulseep(500 * 1000) in vl.c, it improves. > > When cpuspeed service is working in x86_64 host, it becomes: > 994896127 > 994896984 > 994895713 > 994897215 > 994896447 > > It is because CPU is changed from 1.8GHz to 1GHz. TSC is changed dynamically > while QEMU is working. > I think your results are from mobile Pentium III. > I don't know much but a power management of mobile Pentium III works without > software? > > 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. I think the proper solution is to calibrate the TSC regularily and to update the qemu clock accordingly. Of course the patch to read /proc/cpuinfo is still interesting to have a consistant ticks_per_sec. Fabrice.