From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FgGOL-0001FC-5G for qemu-devel@nongnu.org; Wed, 17 May 2006 03:24:21 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FgGOI-0001D4-C8 for qemu-devel@nongnu.org; Wed, 17 May 2006 03:24:20 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FgGOI-0001Cp-3h for qemu-devel@nongnu.org; Wed, 17 May 2006 03:24:18 -0400 Received: from [211.5.2.75] (helo=nm01omta017.dion.ne.jp) by monty-python.gnu.org with smtp (Exim 4.52) id 1FgGR5-0007YC-QV for qemu-devel@nongnu.org; Wed, 17 May 2006 03:27:12 -0400 Message-ID: <005301c67982$e8ea81f0$0464a8c0@athlon> From: "Kazu" References: <200605152203.00826.mr@ramendik.ru> <44695113.8040708@us.ibm.com><000e01c678b3$cd372460$0464a8c0@athlon> <4469BC04.1080809@austin.rr.com> Subject: Re: [Qemu-devel] objective benchmark? Date: Wed, 17 May 2006 16:24:18 +0900 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_004E_01C679CE.58940F80" 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 This is a multi-part message in MIME format. ------=_NextPart_000_004E_01C679CE.58940F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit 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. Regards, Kazu ------=_NextPart_000_004E_01C679CE.58940F80 Content-Type: application/octet-stream; name="qemu-20060517-tps_from_proc.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="qemu-20060517-tps_from_proc.patch" Index: vl.c=0A= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=0A= RCS file: /sources/qemu/qemu/vl.c,v=0A= retrieving revision 1.185=0A= diff -u -r1.185 vl.c=0A= --- vl.c 3 May 2006 22:02:44 -0000 1.185=0A= +++ vl.c 17 May 2006 04:19:00 -0000=0A= @@ -627,8 +627,43 @@=0A= return tv.tv_sec * 1000000LL + tv.tv_usec;=0A= }=0A= =0A= +uint64_t get_tps_from_proc()=0A= +{=0A= + FILE *fp;=0A= + char buf[30];=0A= + double cpu_mhz;=0A= +=0A= + if (!(fp =3D fopen("/proc/cpuinfo", "r")))=0A= + return 0;=0A= +=0A= + /* find wanted line */=0A= + while (fgets(buf, 30, fp) !=3D NULL)=0A= + if (!strncmp(buf, "cpu MHz", 7))=0A= + break;=0A= +=0A= + /* line not found? */=0A= + if (feof(fp)) {=0A= + fclose(fp);=0A= + return 0;=0A= + }=0A= + fclose(fp);=0A= +=0A= + /* put 'cpu MHz' value into cpu_mhz */=0A= + if (!sscanf(&buf[9], ": %lf", &cpu_mhz))=0A= + return 0;=0A= +=0A= + /* return estimated ticks/sec value */=0A= + return (uint64_t)(cpu_mhz * 1000000.0);=0A= +}=0A= +=0A= void cpu_calibrate_ticks(void)=0A= {=0A= + if (!(ticks_per_sec =3D get_tps_from_proc()))=0A= + fprintf(stderr, "Could not obtain ticks/sec. from = /proc/cpuinfo\n \=0A= + resorting to regular method (tsc)\n");=0A= + else /* value obtained, skip below */=0A= + return;=0A= +=0A= int64_t usec, ticks;=0A= =0A= usec =3D get_clock();=0A= @@ -4499,6 +4534,8 @@=0A= tap_win32_poll();=0A= #endif=0A= =0A= + cpu_calibrate_ticks();=0A= +=0A= if (vm_running) {=0A= qemu_run_timers(&active_timers[QEMU_TIMER_VIRTUAL], =0A= qemu_get_clock(vm_clock));=0A= ------=_NextPart_000_004E_01C679CE.58940F80--