Re: [Qemu-devel] objective benchmark?

[Fabrice Bellard <fabrice@bellard.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.