[kvm-devel] kvm very slow
hi, im using a 64 bit fedora7 system with a quad-core processor to host multiple virtual machines. my current kernel is: Linux testserver 2.6.22.1-27.fc7 #1 SMP Tue Jul 17 17:19:58 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux (now there is a 2.6.22.1-33.fc7 to download, but i think it is not the point here). i installed kvm.x86_64: 31-1.fc8 because of a crash i reported as a bug with the older kvm module. this system starts a F7 image with the following command: /usr/bin/qemu-kvm -net nic,macadr=52.54.00.12.34.57 -net tap,script=./ifup.py,ifname=tap0 -hda /var/qemu/vm_images/F7image.img -boot c: -m 512 -vnc :2 -k de inside the image there is fedora 7, but a 32bit system. almost everything works (reboot hangs), but the system is extremely slow! the clock inside the system is extremely slow: every *virtual* second in the image is about two or more seconds in the *real* world. the "clocksource=pit" argument does not help. but it is not only the clock ... the whole system is really slow! on the other side i have an notebook with an old core2 processor which cannot run KVM, so i run qemu/kqemu. if i start the image on this host, i have much better performance. inside the image there is an apache, subversion and a trac; all three systems are really fast on the notebook compared to the quadcore 64bit host! when starting qemu without kqemu i get a warning on console an poor performance. when starting "qemu-kvm" i get no warning, but the same poor performance. how can i check if the kvm-modules are really loaded? any other ideas what i can do? thanks - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm very slow
Ulrich Schreiner wrote: > hi, > > im using a 64 bit fedora7 system with a quad-core processor to host > multiple virtual machines. > > my current kernel is: > > Linux testserver 2.6.22.1-27.fc7 #1 SMP Tue Jul 17 17:19:58 EDT 2007 > x86_64 x86_64 x86_64 GNU/Linux > > (now there is a 2.6.22.1-33.fc7 to download, but i think it is not the > point here). > > i installed > > kvm.x86_64: 31-1.fc8 > > because of a crash i reported as a bug with the older kvm module. > > this system starts a F7 image with the following command: > > /usr/bin/qemu-kvm > -net nic,macadr=52.54.00.12.34.57 > -net tap,script=./ifup.py,ifname=tap0 > -hda /var/qemu/vm_images/F7image.img > -boot c: -m 512 -vnc :2 -k de > > inside the image there is fedora 7, but a 32bit system. > > almost everything works (reboot hangs), but the system is extremely > slow! the clock inside the system is extremely slow: every *virtual* > second in the image is about two or more seconds in the *real* world. > Is there anything in dmesg? What does 'top' report? What does kvm_stat show? -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm very slow
dmesg|grep kvm SELinux: initialized (dev kvmfs, type kvmfs), uses genfs_contexts kvm: emulating exchange as write now booting into a F7 image, after the system is ready (and in idle): top PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 14917 root 20 0 332m 71m 66m S6 0.9 1:17.05 qemu-kvm 14954 root 20 0 14552 1072 812 R0 0.0 0:00.01 top 1 root 20 0 10320 680 572 S0 0.0 0:02.02 init kvm_stat (snapshot): kvm statistics exits12254399 79079 halt_exits 3265434632 invlpg 0 0 io_exits 6539798 74320 irq_exits 43523 29 irq_window 4984 0 mmio_exits1319016 0 pf_fixed 3140955 56 pf_guest 448187 6 request_irq 0 0 signal_exit 39728 0 tlb_flush 29511 31 when logging into the virtual machine (via ssh) the virtual world is very slow: i set the time with "ntpdate" and wait exact one minute in reality. in the virtual image only 24sec are gone! and everything else in the image is really slow. Avi Kivity schrieb: > Ulrich Schreiner wrote: >> hi, >> >> im using a 64 bit fedora7 system with a quad-core processor to host >> multiple virtual machines. >> >> my current kernel is: >> >> Linux testserver 2.6.22.1-27.fc7 #1 SMP Tue Jul 17 17:19:58 EDT 2007 >> x86_64 x86_64 x86_64 GNU/Linux >> >> (now there is a 2.6.22.1-33.fc7 to download, but i think it is not the >> point here). >> >> i installed >> >> kvm.x86_64: 31-1.fc8 >> >> because of a crash i reported as a bug with the older kvm module. >> >> this system starts a F7 image with the following command: >> >> /usr/bin/qemu-kvm -net nic,macadr=52.54.00.12.34.57 -net >> tap,script=./ifup.py,ifname=tap0 >> -hda /var/qemu/vm_images/F7image.img -boot c: -m 512 -vnc :2 -k de >> >> inside the image there is fedora 7, but a 32bit system. >> >> almost everything works (reboot hangs), but the system is extremely >> slow! the clock inside the system is extremely slow: every *virtual* >> second in the image is about two or more seconds in the *real* world. >> > > Is there anything in dmesg? What does 'top' report? What does kvm_stat > show? > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm very slow
Ulrich Schreiner wrote: > dmesg|grep kvm > > SELinux: initialized (dev kvmfs, type kvmfs), uses genfs_contexts > kvm: emulating exchange as write > > There may be messages that aren't prefixed with 'kvm:' (that's a bug btw). Please check. > now booting into a F7 image, after the system is ready (and in idle): > > top >PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > 14917 root 20 0 332m 71m 66m S6 0.9 1:17.05 qemu-kvm > 14954 root 20 0 14552 1072 812 R0 0.0 0:00.01 top > 1 root 20 0 10320 680 572 S0 0.0 0:02.02 init > > kvm_stat (snapshot): > > kvm statistics > > exits12254399 79079 > halt_exits 3265434632 > invlpg 0 0 > io_exits 6539798 74320 > irq_exits 43523 29 > irq_window 4984 0 > mmio_exits1319016 0 > pf_fixed 3140955 56 > pf_guest 448187 6 > request_irq 0 0 > signal_exit 39728 0 > tlb_flush 29511 31 > Wow -- lots of I/O exits. What does 'top' in the guest say? 'hdparm /dev/hda' in the guest? > when logging into the virtual machine (via ssh) the virtual world is > very slow: i set the time with "ntpdate" and wait exact one minute in > reality. in the virtual image only 24sec are gone! > > and everything else in the image is really slow. > > -- error compiling committee.c: too many arguments to function - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm very slow
/sbin/hdparm /dev/sda /dev/sda: IO_support = 0 (default 16-bit) readonly = 0 (off) readahead= 256 (on) geometry = 3263/255/63, sectors = 52428800, start = 0 top in the guest-vm shows nothing special top - 10:27:37 up 13:09, 2 users, load average: 0.05, 0.07, 0.02 Tasks: 74 total, 2 running, 72 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 0.0%sy, 0.0%ni, 99.7%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st Mem:255396k total, 161060k used,94336k free, 8728k buffers Swap: 1048568k total,4k used, 1048564k free,42716k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 4592 root 15 0 2204 976 792 R 0.3 0.4 0:00.04 top 1 root 18 0 2140 636 548 S 0.0 0.2 0:01.44 init 2 root RT 0 000 S 0.0 0.0 0:00.00 migration/0 3 root 34 19 000 S 0.0 0.0 0:00.00 ksoftirqd/0 dmesg in the host: well i cannot find any entries of interest. here is a link to the dmesg: http://usc.innuendo.de/kvm/dmesg.txt Avi Kivity schrieb: > Ulrich Schreiner wrote: >> dmesg|grep kvm >> >> SELinux: initialized (dev kvmfs, type kvmfs), uses genfs_contexts >> kvm: emulating exchange as write >> >> > > There may be messages that aren't prefixed with 'kvm:' (that's a bug > btw). Please check. > >> now booting into a F7 image, after the system is ready (and in idle): >> >> top >>PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND >> 14917 root 20 0 332m 71m 66m S6 0.9 1:17.05 qemu-kvm >> 14954 root 20 0 14552 1072 812 R0 0.0 0:00.01 top >> 1 root 20 0 10320 680 572 S0 0.0 0:02.02 init >> >> kvm_stat (snapshot): >> >> kvm statistics >> >> exits12254399 79079 >> halt_exits 3265434632 >> invlpg 0 0 >> io_exits 6539798 74320 >> irq_exits 43523 29 >> irq_window 4984 0 >> mmio_exits1319016 0 >> pf_fixed 3140955 56 >> pf_guest 448187 6 >> request_irq 0 0 >> signal_exit 39728 0 >> tlb_flush 29511 31 >> > > Wow -- lots of I/O exits. What does 'top' in the guest say? 'hdparm > /dev/hda' in the guest? > >> when logging into the virtual machine (via ssh) the virtual world is >> very slow: i set the time with "ntpdate" and wait exact one minute in >> reality. in the virtual image only 24sec are gone! >> >> and everything else in the image is really slow. >> >> > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm very slow
no ideas what can be done? why it is so slow? i've tried the "-L /usr/shar/kvm" to use the kvm-bios but no better performance ... Am Donnerstag, den 02.08.2007, 11:24 +0300 schrieb Avi Kivity: > Ulrich Schreiner wrote: > > dmesg|grep kvm > > > > SELinux: initialized (dev kvmfs, type kvmfs), uses genfs_contexts > > kvm: emulating exchange as write > > > > > > There may be messages that aren't prefixed with 'kvm:' (that's a bug > btw). Please check. > > > now booting into a F7 image, after the system is ready (and in idle): > > > > top > >PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > > 14917 root 20 0 332m 71m 66m S6 0.9 1:17.05 qemu-kvm > > 14954 root 20 0 14552 1072 812 R0 0.0 0:00.01 top > > 1 root 20 0 10320 680 572 S0 0.0 0:02.02 init > > > > kvm_stat (snapshot): > > > > kvm statistics > > > > exits12254399 79079 > > halt_exits 3265434632 > > invlpg 0 0 > > io_exits 6539798 74320 > > irq_exits 43523 29 > > irq_window 4984 0 > > mmio_exits1319016 0 > > pf_fixed 3140955 56 > > pf_guest 448187 6 > > request_irq 0 0 > > signal_exit 39728 0 > > tlb_flush 29511 31 > > > > Wow -- lots of I/O exits. What does 'top' in the guest say? 'hdparm > /dev/hda' in the guest? > > > when logging into the virtual machine (via ssh) the virtual world is > > very slow: i set the time with "ntpdate" and wait exact one minute in > > reality. in the virtual image only 24sec are gone! > > > > and everything else in the image is really slow. > > > > > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm very slow
>no ideas what can be done? why it is so slow? Let's try to catch the cause for the 74k ioexits per second. Please add #define DEBUG_IOPORT in qemu/vl.c and qemu/exec.c and recompile. After that when the guest runs and does 74k ioexits on idle, enter the qemu's monitor (ctrl-alt-1) enter 'log ioport'. All guest's ioport access will be written to /tmp/qemu.log. Be kind enough to calculate the statistics of ioport access per port number a second. With the numbers we can see the hardware that causes the slowness. -- Dor. btw: are you using kvm-33 or older? > >i've tried the "-L /usr/shar/kvm" to use the kvm-bios but no better >performance ... > >Am Donnerstag, den 02.08.2007, 11:24 +0300 schrieb Avi Kivity: >> Ulrich Schreiner wrote: >> > dmesg|grep kvm >> > >> > SELinux: initialized (dev kvmfs, type kvmfs), uses genfs_contexts >> > kvm: emulating exchange as write >> > >> > >> >> There may be messages that aren't prefixed with 'kvm:' (that's a bug >> btw). Please check. >> >> > now booting into a F7 image, after the system is ready (and in >idle): >> > >> > top >> >PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ >COMMAND >> > 14917 root 20 0 332m 71m 66m S6 0.9 1:17.05 qemu- >kvm >> > 14954 root 20 0 14552 1072 812 R0 0.0 0:00.01 top >> > 1 root 20 0 10320 680 572 S0 0.0 0:02.02 init >> > >> > kvm_stat (snapshot): >> > >> > kvm statistics >> > >> > exits12254399 79079 >> > halt_exits 3265434632 >> > invlpg 0 0 >> > io_exits 6539798 74320 >> > irq_exits 43523 29 >> > irq_window 4984 0 >> > mmio_exits1319016 0 >> > pf_fixed 3140955 56 >> > pf_guest 448187 6 >> > request_irq 0 0 >> > signal_exit 39728 0 >> > tlb_flush 29511 31 >> > >> >> Wow -- lots of I/O exits. What does 'top' in the guest say? 'hdparm >> /dev/hda' in the guest? >> >> > when logging into the virtual machine (via ssh) the virtual world is >> > very slow: i set the time with "ntpdate" and wait exact one minute >in >> > reality. in the virtual image only 24sec are gone! >> > >> > and everything else in the image is really slow. >> > >> > >> > > >--- - >- >This SF.net email is sponsored by: Splunk Inc. >Still grepping through log files to find problems? Stop. >Now Search log events and configuration files using AJAX and a browser. >Download your FREE copy of Splunk now >> http://get.splunk.com/ >___ >kvm-devel mailing list >kvm-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm very slow
today morning i compiled kvm-33 and the output of kvm-stat is much better now (guest in idle): kvm statistics efer_reload 109442736504 exits137226886967 halt_exits1084344 935 invlpg 0 0 io_exits 76689145070 irq_exits 27886 2 irq_window 11477 1 light_exits 2778416 462 mmio_exits2153709 498 pf_fixed 1085923 0 pf_guest 459144 0 request_irq 0 0 signal_exit 25818 0 tlb_flush 228295 5 i don't know if these numbers are ok; do you still need the generated qemu.log for ioport access? if you need it i will upload it to my public server. but: the system is slow. it is extremely slow when booting and the guest-system clock ist twice as slow as the host-system clock (both are idle; ok, the host as a runnung qemu-instance :-). when starting i get: Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a fatal error, but for better emulation accuracy either use a 2.6 host Linux kernel or type 'echo 1024 > /proc/sys/dev/rtc/max-user-freq' as root. well i HAVE a 2.6kernel (2.6.22.1-41.fc7), but i cannot set dev.rtc.max-user-freq, i only can set the high precision event timer dev.hpet.max-user-freq = 1024 which i have done. but the message always appears. i don't know if this is ignorable. Am Dienstag, den 07.08.2007, 00:44 -0700 schrieb Dor Laor: > >no ideas what can be done? why it is so slow? > > Let's try to catch the cause for the 74k ioexits per second. > Please add #define DEBUG_IOPORT in qemu/vl.c and qemu/exec.c and > recompile. > After that when the guest runs and does 74k ioexits on idle, enter the > qemu's monitor (ctrl-alt-1) > enter 'log ioport'. All guest's ioport access will be written to > /tmp/qemu.log. > Be kind enough to calculate the statistics of ioport access per port > number a second. > With the numbers we can see the hardware that causes the slowness. > -- Dor. > > btw: are you using kvm-33 or older? > > > > >i've tried the "-L /usr/shar/kvm" to use the kvm-bios but no better > >performance ... > > > >Am Donnerstag, den 02.08.2007, 11:24 +0300 schrieb Avi Kivity: > >> Ulrich Schreiner wrote: > >> > dmesg|grep kvm > >> > > >> > SELinux: initialized (dev kvmfs, type kvmfs), uses genfs_contexts > >> > kvm: emulating exchange as write > >> > > >> > > >> > >> There may be messages that aren't prefixed with 'kvm:' (that's a bug > >> btw). Please check. > >> > >> > now booting into a F7 image, after the system is ready (and in > >idle): > >> > > >> > top > >> >PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ > >COMMAND > >> > 14917 root 20 0 332m 71m 66m S6 0.9 1:17.05 qemu- > >kvm > >> > 14954 root 20 0 14552 1072 812 R0 0.0 0:00.01 top > >> > 1 root 20 0 10320 680 572 S0 0.0 0:02.02 init > >> > > >> > kvm_stat (snapshot): > >> > > >> > kvm statistics > >> > > >> > exits12254399 79079 > >> > halt_exits 3265434632 > >> > invlpg 0 0 > >> > io_exits 6539798 74320 > >> > irq_exits 43523 29 > >> > irq_window 4984 0 > >> > mmio_exits1319016 0 > >> > pf_fixed 3140955 56 > >> > pf_guest 448187 6 > >> > request_irq 0 0 > >> > signal_exit 39728 0 > >> > tlb_flush 29511 31 > >> > > >> > >> Wow -- lots of I/O exits. What does 'top' in the guest say? 'hdparm > >> /dev/hda' in the guest? > >> > >> > when logging into the virtual machine (via ssh) the virtual world > is > >> > very slow: i set the time with "ntpdate" and wait exact one minute > >in > >> > reality. in the virtual image only 24sec are gone! > >> > > >> > and everything else in the image is really slow. > >> > > >> > > >> > > > > > >--- > - > >- > >This SF.net email is sponsored by: Splunk Inc. > >Still grepping through log files to find problems? Stop. > >Now Search log events and configuration files using AJAX and a browser. > >Download your FREE copy of Splunk now >> http://get.splunk.com/ > >___ > >kvm-devel mailing list > >kvm-devel@lists.sourceforge.net > >https://lists.sourceforge.net/lists/listinfo/kvm-devel - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm very slow
On 8/7/07, Ulrich Schreiner <[EMAIL PROTECTED]> wrote: > Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a > fatal > error, but for better emulation accuracy either use a 2.6 host Linux > kernel or > type 'echo 1024 > /proc/sys/dev/rtc/max-user-freq' as root. > > well i HAVE a 2.6kernel (2.6.22.1-41.fc7), but i cannot set > dev.rtc.max-user-freq, i only can set the high precision event timer > > dev.hpet.max-user-freq = 1024 Known issue, it's unrelated to KVM. HPET is using the same IRQ as the cmos RTC so only on of them can deliver the periodical interrupt. I think that work to program the HPET in dont-break-other-stuff mode is underway. Luca - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm very slow
>today morning i compiled kvm-33 and the output of kvm-stat is much >better now (guest in idle): > >kvm statistics > > efer_reload 109442736504 > exits137226886967 > halt_exits1084344 935 > invlpg 0 0 > io_exits 76689145070 > irq_exits 27886 2 > irq_window 11477 1 > light_exits 2778416 462 > mmio_exits2153709 498 > pf_fixed 1085923 0 > pf_guest 459144 0 > request_irq 0 0 > signal_exit 25818 0 > tlb_flush 228295 5 It's much better. What does the guest do? It's weird it reloads the efer. > > >i don't know if these numbers are ok; do you still need the generated >qemu.log for ioport access? if you need it i will upload it to my public >server. > >but: the system is slow. it is extremely slow when booting and the >guest-system clock ist twice as slow as the host-system clock (both are >idle; ok, the host as a runnung qemu-instance :-). > >when starting i get: > >Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a >fatal >error, but for better emulation accuracy either use a 2.6 host Linux >kernel or >type 'echo 1024 > /proc/sys/dev/rtc/max-user-freq' as root. > >well i HAVE a 2.6kernel (2.6.22.1-41.fc7), but i cannot set >dev.rtc.max-user-freq, i only can set the high precision event timer > >dev.hpet.max-user-freq = 1024 > >which i have done. but the message always appears. i don't know if this >is ignorable. > The problem is that qemu calculates time using either sigalarm or rtc. (the later in more accurate) Seems like qemu doesn't get enough signals to inject timer irq to the guest. Luca claims the HPET intefer the RTC. Can it be disabled? ( I know some new chipsets implement rtc using HPET). - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm very slow
On 8/7/07, Dor Laor <[EMAIL PROTECTED]> wrote: > Luca claims the HPET intefer the RTC. Can it be disabled? ( I know some > new chipsets implement rtc using HPET). Basically HPET can operate in legacy mode - where it uses the same IRQ as the RTC (and RTC won't deliver any interrupt) - or in "standard" mode where the IO-APIC can be configured to deliver the interrupt on any line. ATM Linux can only use the legacy mode. You can of course disable HPET, but then it won't be available for in-kernel timekeeping (in case e.g. the TSC is not stable/synced). I'd rather add support for HPET as timer in QEMU... On the original issue: if the host is running at HZ=100 then the precision of the timer may be a awkward (usually around 20ms), but it's surprising that it causes such a huge drift. Luca - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm very slow
well there are running some "default F7 daemons". yum-updatesd (python) setroubleshootd (python) hald ... but no process is really running, when doing a "htop" i the processor has a load of 0.7% what is the "efer_reload"? while i'm writing this email i have kvm_stat in another shell in the background and this value always is between 5000 and 7000 btw: i patched kvm_stat to make the screen refresh faster/slower, so that i can mark the output with the mouse and copy it (to my posts :-). is there a need for this? Am Dienstag, den 07.08.2007, 04:51 -0700 schrieb Dor Laor: > >today morning i compiled kvm-33 and the output of kvm-stat is much > >better now (guest in idle): > > > >kvm statistics > > > > efer_reload 109442736504 > > exits137226886967 > > halt_exits1084344 935 > > invlpg 0 0 > > io_exits 76689145070 > > irq_exits 27886 2 > > irq_window 11477 1 > > light_exits 2778416 462 > > mmio_exits2153709 498 > > pf_fixed 1085923 0 > > pf_guest 459144 0 > > request_irq 0 0 > > signal_exit 25818 0 > > tlb_flush 228295 5 > > > It's much better. What does the guest do? It's weird it reloads the > efer. > > > > > > >i don't know if these numbers are ok; do you still need the generated > >qemu.log for ioport access? if you need it i will upload it to my > public > >server. > > > >but: the system is slow. it is extremely slow when booting and the > >guest-system clock ist twice as slow as the host-system clock (both are > >idle; ok, the host as a runnung qemu-instance :-). > > > >when starting i get: > > > >Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a > >fatal > >error, but for better emulation accuracy either use a 2.6 host Linux > >kernel or > >type 'echo 1024 > /proc/sys/dev/rtc/max-user-freq' as root. > > > >well i HAVE a 2.6kernel (2.6.22.1-41.fc7), but i cannot set > >dev.rtc.max-user-freq, i only can set the high precision event timer > > > >dev.hpet.max-user-freq = 1024 > > > >which i have done. but the message always appears. i don't know if this > >is ignorable. > > > > The problem is that qemu calculates time using either sigalarm or rtc. > (the later in more accurate) > Seems like qemu doesn't get enough signals to inject timer irq to the > guest. > > Luca claims the HPET intefer the RTC. Can it be disabled? ( I know some > new chipsets implement rtc using HPET). > - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm very slow
>> Luca claims the HPET intefer the RTC. Can it be disabled? ( I know >some >> new chipsets implement rtc using HPET). > >Basically HPET can operate in legacy mode - where it uses the same IRQ >as the RTC (and RTC won't deliver any interrupt) - or in "standard" >mode where the IO-APIC can be configured to deliver the interrupt on >any line. ATM Linux can only use the legacy mode. >You can of course disable HPET, but then it won't be available for >in-kernel timekeeping (in case e.g. the TSC is not stable/synced). I'd >rather add support for HPET as timer in QEMU... >On the original issue: if the host is running at HZ=100 then the >precision of the timer may be a awkward (usually around 20ms), but >it's surprising that it causes such a huge drift. We're experiencing guest clock drifts even when the host is running with HZ=1000. But so far there were no performance problmes around it. It's worth a shot anyway. Another option is to use -tdf for qemu command line (stands for TimeDriftFix). The option make qemu push more pit irqs to the guest until the required ack number is reached. For the general case there is work in progress to fix these types of timing issues. We intend to do the following: 1. Make qemu support dyn-tick (almost done) 2. Add compensation support for all guest time sources (pit, acpi,..) 3. Add kernel ioctl command to receive accurate time source (based on hrtimer) for hosts without dyn-tick (which provides accurate high precision user space timers). --Dor - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm very slow
> We're experiencing guest clock drifts even when the host is running with > HZ=1000. > But so far there were no performance problmes around it. > It's worth a shot anyway. > are there any benchmarkings (and tools) which i can run inside the guest? are there any official results with which i can compare? my "performance problem" is that i have an image with an applicationserver (python based) inside and this server performs better (faster response times, more request/sec) when run with qemu/kqemu on my 1-year-old-sonynotebook (32-bit fedora7) compared to a quadcore 2month old dell-server (64-bit fedora7) and qemu/kvm :-). well ... it works, but it is a little disappointing. the wrong timer is really awkward, because the time in the guest drifts extremly (about half of real time) so the "ntpd" does not automatically set update time because after some time the drift is so big, that ntpd will not set the system time. i had to disable ntpd and start a cronjob every minute to set the current time! so i only loose every second minute. my timestamps in the database for my webapp are ... well mostly ok. but i cannot use this scenario for a productive system of my webapp. i don't know if this behaviour (rtc/hpe) has impact on the performance (hopefully, because you wrote work in on the way). - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm very slow
[EMAIL PROTECTED] wrote: >>> Luca claims the HPET intefer the RTC. Can it be disabled? ( I know >>> some new chipsets implement rtc using HPET). >> >> Basically HPET can operate in legacy mode - where it uses the same >> IRQ as the RTC (and RTC won't deliver any interrupt) - or in >> "standard" mode where the IO-APIC can be configured to deliver the >> interrupt on any line. ATM Linux can only use the legacy mode. >> You can of course disable HPET, but then it won't be available for >> in-kernel timekeeping (in case e.g. the TSC is not stable/synced). >> I'd rather add support for HPET as timer in QEMU... >> On the original issue: if the host is running at HZ=100 then the >> precision of the timer may be a awkward (usually around 20ms), but >> it's surprising that it causes such a huge drift. > > We're experiencing guest clock drifts even when the host is > running with HZ=1000. > But so far there were no performance problmes around it. > It's worth a shot anyway. > > Another option is to use -tdf for qemu command line (stands > for TimeDriftFix). > The option make qemu push more pit irqs to the guest until the > required ack number is reached. > > For the general case there is work in progress to fix these > types of timing issues. > We intend to do the following: > 1. Make qemu support dyn-tick (almost done) > 2. Add compensation support for all guest time sources (pit, acpi,..) > 3. Add kernel ioctl command to receive accurate time source (based on > hrtimer) for hosts without dyn-tick (which provides accurate high > precision user space timers). > Even with this, the guest time will still have 20-30% drift since Linux guest TSC handler will cross refer the PIT irq with TSC value to pick up the lost ticks which works fine for native but bring many un necessary compensation in guest side. Simplying adding compensation timer irq to guest solve part of the issues, but still painful. Xen took an aggresive approach to fix this by precisely sync guest time resource together such as PIT, TSC, RTC etc. But it is too complicated and still doesn;t solve the whole problem in SMP situation, it may be not necessay in KVM. BTW, Vmware also has similar time virtualization issue. pv TSC time resource may solve this issue finally. thx,eddie - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm very slow
>>> Basically HPET can operate in legacy mode - where it uses the same >>> IRQ as the RTC (and RTC won't deliver any interrupt) - or in >>> "standard" mode where the IO-APIC can be configured to deliver the >>> interrupt on any line. ATM Linux can only use the legacy mode. >>> You can of course disable HPET, but then it won't be available for >>> in-kernel timekeeping (in case e.g. the TSC is not stable/synced). >>> I'd rather add support for HPET as timer in QEMU... >>> On the original issue: if the host is running at HZ=100 then the >>> precision of the timer may be a awkward (usually around 20ms), but >>> it's surprising that it causes such a huge drift. >> >> We're experiencing guest clock drifts even when the host is >> running with HZ=1000. >> But so far there were no performance problmes around it. >> It's worth a shot anyway. >> >> Another option is to use -tdf for qemu command line (stands >> for TimeDriftFix). >> The option make qemu push more pit irqs to the guest until the >> required ack number is reached. >> >> For the general case there is work in progress to fix these >> types of timing issues. >> We intend to do the following: >> 1. Make qemu support dyn-tick (almost done) >> 2. Add compensation support for all guest time sources (pit, acpi,..) >> 3. Add kernel ioctl command to receive accurate time source (based on >> hrtimer) for hosts without dyn-tick (which provides accurate high >> precision user space timers). >> >Even with this, the guest time will still have 20-30% drift since Linux >guest TSC handler >will cross refer the PIT irq with TSC value to pick up the lost ticks >which works fine for >native but bring many un necessary compensation in guest side. Simplying >adding >compensation timer irq to guest solve part of the issues, but still >painful. Xen took an >aggresive approach to fix this by precisely sync guest time resource >together such as >PIT, TSC, RTC etc. But it is too complicated and still doesn;t solve the >whole >problem in SMP situation, it may be not necessay in KVM. You're right that we need to sync all time sources, I just want to start with the first. Since non-acpi windows uses PIT we chose to start with it. > >BTW, Vmware also has similar time virtualization issue. pv TSC time >resource may solve >this issue finally. It should also work for HVMs. I know that VMware also changed ntp, probably because their virtualize time is not perfect. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm very slow
Il Tue, Aug 07, 2007 at 02:08:08PM +0200, Luca ha scritto:
> On 8/7/07, Dor Laor <[EMAIL PROTECTED]> wrote:
> > Luca claims the HPET intefer the RTC. Can it be disabled? ( I know some
> > new chipsets implement rtc using HPET).
>
> Basically HPET can operate in legacy mode - where it uses the same IRQ
> as the RTC (and RTC won't deliver any interrupt) - or in "standard"
> mode where the IO-APIC can be configured to deliver the interrupt on
> any line. ATM Linux can only use the legacy mode.
> You can of course disable HPET, but then it won't be available for
> in-kernel timekeeping (in case e.g. the TSC is not stable/synced). I'd
> rather add support for HPET as timer in QEMU...
Something like this. Ulrich can you give it a try:
---
Patch against current GIT, but also applies to kvm-33.
Run kvm with -use-hpet.
qemu/vl.c | 62 ++--
1 file changed, 60 insertions(+), 2 deletions(-)
diff --git a/qemu/vl.c b/qemu/vl.c
index 4ad39f1..36628af 100644
--- a/qemu/vl.c
+++ b/qemu/vl.c
@@ -54,6 +54,7 @@
#include
#include
#include
+#include
#include
#endif
#endif
@@ -996,8 +997,9 @@ static void host_alarm_handler(int host_signum)
static int use_rtc = 1;
static int rtc_fd;
+static int use_hpet;
-static int start_rtc_timer(void)
+static int enable_rtc(void)
{
rtc_fd = open("/dev/rtc", O_RDONLY);
if (rtc_fd < 0)
@@ -1017,6 +1019,56 @@ static int start_rtc_timer(void)
return 0;
}
+static char default_hpet[] = "/dev/hpet";
+
+static int enable_hpet(void)
+{
+struct hpet_info info;
+int r;
+
+rtc_fd = open(default_hpet, O_RDONLY);
+if (rtc_fd < 0)
+return -1;
+
+/* Set frequency */
+r = ioctl(rtc_fd, HPET_IRQFREQ, RTC_FREQ);
+if (r < 0) {
+fprintf(stderr, "Could not configure '/dev/hpet' to have a 1024 Hz
timer. This is not a fatal\n"
+"error, but for better emulation accuracy type:\n"
+"'echo 1024 > /proc/sys/dev/hpet/max-user-freq' as root.\n");
+goto fail;
+}
+
+/* Check capabilities */
+r = ioctl(rtc_fd, HPET_INFO, &info);
+if (r < 0)
+goto fail;
+
+/* Enable peridic mode */
+r = ioctl(rtc_fd, HPET_EPI, 0);
+if (info.hi_flags && (r < 0))
+goto fail;
+
+/* Enable interrupt */
+r = ioctl(rtc_fd, HPET_IE_ON, 0);
+if (r < 0)
+goto fail;
+
+pit_min_timer_count = PIT_FREQ / RTC_FREQ;
+
+return 0;
+fail:
+close(rtc_fd);
+return -1;
+}
+
+static int start_rtc_timer(void)
+{
+if (use_hpet)
+return enable_hpet();
+else
+return enable_rtc();
+}
#else
static int start_rtc_timer(void)
@@ -1090,7 +1142,7 @@ static void init_timer_alarm(void)
2.6 kernels */
if (itv.it_interval.tv_usec > 1000 || 1) {
/* try to use /dev/rtc to have a faster timer */
-if (!use_rtc || (start_rtc_timer() < 0))
+if ((!use_rtc && !use_hpet) || (start_rtc_timer() < 0))
goto use_itimer;
/* disable itimer */
itv.it_interval.tv_sec = 0;
@@ -6482,6 +6534,7 @@ void help(void)
"-tdfinject timer interrupts that got lost\n"
#if defined(__linux__)
"-no-rtc don't use /dev/rtc for timer alarm (do use
gettimeofday)\n"
+ "-use-rtcuse /dev/hpet (HPET) for timer alarm (do use
gettimeofday)\n"
#endif
"-option-rom rom load a file, rom, into the option ROM space\n"
"\n"
@@ -6574,6 +6627,7 @@ enum {
QEMU_OPTION_tdf,
#if defined(__linux__)
QEMU_OPTION_no_rtc,
+QEMU_OPTION_use_hpet,
#endif
QEMU_OPTION_cpu_vendor,
};
@@ -6671,6 +6725,7 @@ const QEMUOption qemu_options[] = {
{ "tdf", 0, QEMU_OPTION_tdf }, /* enable time drift fix */
#if defined(__linux__)
{ "no-rtc", 0, QEMU_OPTION_no_rtc },
+{ "use-hpet", 0, QEMU_OPTION_use_hpet },
#endif
{ "cpu-vendor", HAS_ARG, QEMU_OPTION_cpu_vendor },
{ NULL },
@@ -7395,6 +7450,9 @@ int main(int argc, char **argv)
case QEMU_OPTION_no_rtc:
use_rtc = 0;
break;
+ case QEMU_OPTION_use_hpet:
+ use_hpet = 1;
+ break;
#endif
case QEMU_OPTION_cpu_vendor:
cpu_vendor_string = optarg;
Luca
--
I went to God just to see
And I was looking at me
Saw heaven and hell were lies
When I'm God everyone dies
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
kvm-devel mailing list
kvm-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm very slow
ok,
patched kvm-33, compile, install
i started qemu-system-x86_64 with "-no-rtc -use-hpet" and ... well the
time drift is unchanged. ok, the warning for "dev.rtc..." has gone.
doing a date (guest) gives me (for example):
8:08:59
after 10 (real!) seconds, date (guest) gives me
8:09:04
--> 10 real seconds are about 5 seconds in the guest. working about 5
minutes in the guest and the clock drifts a few minutes in the past.
ps: the line
"-use-rtcuse /dev/hpet (HPET) for timer alarm (do use
gettimeofday)\n"
should be
"-use-hpetuse /dev/hpet (HPET) for timer alarm (do use
gettimeofday)\n"
because "use-hpet" is the option which is aksed in the code
Am Dienstag, den 07.08.2007, 22:49 +0200 schrieb Luca Tettamanti:
> Il Tue, Aug 07, 2007 at 02:08:08PM +0200, Luca ha scritto:
> > On 8/7/07, Dor Laor <[EMAIL PROTECTED]> wrote:
> > > Luca claims the HPET intefer the RTC. Can it be disabled? ( I know some
> > > new chipsets implement rtc using HPET).
> >
> > Basically HPET can operate in legacy mode - where it uses the same IRQ
> > as the RTC (and RTC won't deliver any interrupt) - or in "standard"
> > mode where the IO-APIC can be configured to deliver the interrupt on
> > any line. ATM Linux can only use the legacy mode.
> > You can of course disable HPET, but then it won't be available for
> > in-kernel timekeeping (in case e.g. the TSC is not stable/synced). I'd
> > rather add support for HPET as timer in QEMU...
>
> Something like this. Ulrich can you give it a try:
>
> ---
> Patch against current GIT, but also applies to kvm-33.
> Run kvm with -use-hpet.
>
> qemu/vl.c | 62 ++--
> 1 file changed, 60 insertions(+), 2 deletions(-)
>
> diff --git a/qemu/vl.c b/qemu/vl.c
> index 4ad39f1..36628af 100644
> --- a/qemu/vl.c
> +++ b/qemu/vl.c
> @@ -54,6 +54,7 @@
> #include
> #include
> #include
> +#include
> #include
> #endif
> #endif
> @@ -996,8 +997,9 @@ static void host_alarm_handler(int host_signum)
>
> static int use_rtc = 1;
> static int rtc_fd;
> +static int use_hpet;
>
> -static int start_rtc_timer(void)
> +static int enable_rtc(void)
> {
> rtc_fd = open("/dev/rtc", O_RDONLY);
> if (rtc_fd < 0)
> @@ -1017,6 +1019,56 @@ static int start_rtc_timer(void)
> return 0;
> }
>
> +static char default_hpet[] = "/dev/hpet";
> +
> +static int enable_hpet(void)
> +{
> +struct hpet_info info;
> +int r;
> +
> +rtc_fd = open(default_hpet, O_RDONLY);
> +if (rtc_fd < 0)
> +return -1;
> +
> +/* Set frequency */
> +r = ioctl(rtc_fd, HPET_IRQFREQ, RTC_FREQ);
> +if (r < 0) {
> +fprintf(stderr, "Could not configure '/dev/hpet' to have a 1024 Hz
> timer. This is not a fatal\n"
> +"error, but for better emulation accuracy type:\n"
> +"'echo 1024 > /proc/sys/dev/hpet/max-user-freq' as root.\n");
> +goto fail;
> +}
> +
> +/* Check capabilities */
> +r = ioctl(rtc_fd, HPET_INFO, &info);
> +if (r < 0)
> +goto fail;
> +
> +/* Enable peridic mode */
> +r = ioctl(rtc_fd, HPET_EPI, 0);
> +if (info.hi_flags && (r < 0))
> +goto fail;
> +
> +/* Enable interrupt */
> +r = ioctl(rtc_fd, HPET_IE_ON, 0);
> +if (r < 0)
> +goto fail;
> +
> +pit_min_timer_count = PIT_FREQ / RTC_FREQ;
> +
> +return 0;
> +fail:
> +close(rtc_fd);
> +return -1;
> +}
> +
> +static int start_rtc_timer(void)
> +{
> +if (use_hpet)
> +return enable_hpet();
> +else
> +return enable_rtc();
> +}
> #else
>
> static int start_rtc_timer(void)
> @@ -1090,7 +1142,7 @@ static void init_timer_alarm(void)
> 2.6 kernels */
> if (itv.it_interval.tv_usec > 1000 || 1) {
> /* try to use /dev/rtc to have a faster timer */
> -if (!use_rtc || (start_rtc_timer() < 0))
> +if ((!use_rtc && !use_hpet) || (start_rtc_timer() < 0))
> goto use_itimer;
> /* disable itimer */
> itv.it_interval.tv_sec = 0;
> @@ -6482,6 +6534,7 @@ void help(void)
> "-tdfinject timer interrupts that got lost\n"
> #if defined(__linux__)
> "-no-rtc don't use /dev/rtc for timer alarm (do use
> gettimeofday)\n"
> + "-use-rtcuse /dev/hpet (HPET) for timer alarm (do use
> gettimeofday)\n"
> #endif
> "-option-rom rom load a file, rom, into the option ROM space\n"
> "\n"
> @@ -6574,6 +6627,7 @@ enum {
> QEMU_OPTION_tdf,
> #if defined(__linux__)
> QEMU_OPTION_no_rtc,
> +QEMU_OPTION_use_hpet,
> #endif
> QEMU_OPTION_cpu_vendor,
> };
> @@ -6671,6 +6725,7 @@ const QEMUOption qemu_options[] = {
> { "tdf", 0, QEMU_OPTION_tdf }, /* enable time drift fix */
> #if defined(__linux__)
> { "no-rtc", 0, QEMU_OPTION_no_rtc },
> +{ "use-hpet", 0, QEMU_OPTION_use_hpet },
> #endif
> { "cpu-vendor", HAS_ARG, QEMU
Re: [kvm-devel] kvm very slow
On Wed, 2007-01-08 at 07:22 +0200, Ulrich Schreiner wrote: > hi, > > im using a 64 bit fedora7 system with a quad-core processor to host > multiple virtual machines. > literally the exact same setup here > my current kernel is: > > Linux testserver 2.6.22.1-27.fc7 #1 SMP Tue Jul 17 17:19:58 EDT 2007 > x86_64 x86_64 x86_64 GNU/Linux > > (now there is a 2.6.22.1-33.fc7 to download, but i think it is not the > point here). > 2.6.22.1-41.fc7 x86_64 host > i installed > > kvm.x86_64: 31-1.fc8 kvm-33 > > because of a crash i reported as a bug with the older kvm module. > > this system starts a F7 image with the following command: > > /usr/bin/qemu-kvm > -net nic,macadr=52.54.00.12.34.57 > -net tap,script=./ifup.py,ifname=tap0 > -hda /var/qemu/vm_images/F7image.img > -boot c: -m 512 -vnc :2 -k de > > inside the image there is fedora 7, but a 32bit system. > almost exact same as here except using 32 bit fedora rawhide (development) guest running kernel 2.6.23-0.74.rc2.git1.fc8 > almost everything works (reboot hangs), but the system is extremely > slow! the clock inside the system is extremely slow: every *virtual* > second in the image is about two or more seconds in the *real* world. and I'm having the exact same issue here. The hardware clock works fine (least from the output of /proc/driver/rtc and hwclock) but the system time quickly falls behind in the guest, approx 0.5 secs for every 1 real second. No combination of selecting different clocksources in the guest, disabling CONFIG_NO_HZ, etc seemed to make any difference. And the fact is my fc7 x86_64 install works just great so I doubt its the host. What I did notice though was ACPI wasn't being enabled by default for the 32bit kernel with the message ACPI: no DMI BIOS year, acpi=force is required to enable ACPI and that the acpi_pm clocksource the x86_64 guest picked by default, which worked fine, was missing. eg: 2.6.23-0.74.rc2.git1.fc8 i686 default boot: /sys/devices/system/clocksource/clocksource0/available_clocksource pit jiffies tsc /sys/devices/system/clocksource/clocksource0/current_clocksource pit 2.6.23-0.74.rc2.git1.fc8 i686 with acpi=force: /sys/devices/system/clocksource/clocksource0/available_clocksource tsc acpi_pm pit jiffies /sys/devices/system/clocksource/clocksource0/current_clocksource tsc and now everything seems great, hardware and system time seem 1:1 again. Attached is a diff of the dmesg from each boot. As to why this is... -- Matthew Kent <[EMAIL PROTECTED]> http://magoazul.com --- dmesg.f7_32bit_default 2007-08-09 16:00:00.0 -0700 +++ dmesg.f7_32bit_forced_acpi 2007-08-09 15:59:55.0 -0700 @@ -34,21 +34,30 @@ ACPI: FACS 1FFF00C0, 0040 ACPI: APIC 1FFF0938, 0040 (r1 QEMU QEMUAPIC1 QEMU1) ACPI: no DMI BIOS year, acpi=force is required to enable ACPI -ACPI: Disabling ACPI support +ACPI: acpi=force override +ACPI: PM-Timer IO Port: 0xb008 +ACPI: Local APIC address 0xfee0 +ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) +Processor #0 6:2 APIC version 17 +ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) +IOAPIC[0]: apic_id 1, version 17, address 0xfec0, GSI 0-23 +ACPI: IRQ11 used by override. +Enabling APIC mode: Flat. Using 1 I/O APICs +Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 3000 (gap: 2000:dffc) swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000e8000 swsusp: Registered nosave memory region: 000e8000 - 0010 Built 1 zonelists in Zone order. Total pages: 129265 -Kernel command line: ro root=/dev/VolGroup00/LogVol00 console=tty0 console=ttyS0 debug -Found and enabled local APIC! +Kernel command line: ro root=/dev/VolGroup00/LogVol00 console=tty0 console=ttyS0 debug acpi=force mapped APIC to b000 (fee0) +mapped IOAPIC to a000 (fec0) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 CPU 0 irqstacks, hard=c0817000 soft=c07f7000 PID hash table entries: 2048 (order: 11, 8192 bytes) -Detected 2400.636 MHz processor. +Detected 2400.387 MHz processor. Console: colour VGA+ 80x25 console [tty0] enabled console [ttyS0] enabled @@ -75,7 +84,7 @@ .text : 0xc040 - 0xc063074d (2241 kB) Checking if this processor honours the WP bit even in supervisor mode... Ok. SLUB: Genslabs=22, HWalign=64, Order=0-1, MinObjects=4, CPUs=1, Nodes=1 -Calibrating delay using timer specific routine.. 9619.97 BogoMIPS (lpj=4809986) +Calibrating delay using timer specific routine.. 9622.99 BogoMIPS (lpj=4811496) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode @@ -92,8 +101,13 @@ Checking 'hlt' instruction... OK. SMP alternatives: switching to UP code Freeing SMP alternatives: 12k freed +ACPI: Core revision 20070126 CPU0: Intel QEM
Re: [kvm-devel] kvm very slow
[oops sorry. should have included the full dmesg from the bad boot and cc'd the original poster] On Thu, 2007-09-08 at 16:23 -0700, Matthew Kent wrote: > On Wed, 2007-01-08 at 07:22 +0200, Ulrich Schreiner wrote: > > hi, > > > > im using a 64 bit fedora7 system with a quad-core processor to host > > multiple virtual machines. > > > > literally the exact same setup here > > > my current kernel is: > > > > Linux testserver 2.6.22.1-27.fc7 #1 SMP Tue Jul 17 17:19:58 EDT 2007 > > x86_64 x86_64 x86_64 GNU/Linux > > > > (now there is a 2.6.22.1-33.fc7 to download, but i think it is not the > > point here). > > > > 2.6.22.1-41.fc7 x86_64 host > > > i installed > > > > kvm.x86_64: 31-1.fc8 > > kvm-33 > > > > > because of a crash i reported as a bug with the older kvm module. > > > > this system starts a F7 image with the following command: > > > > /usr/bin/qemu-kvm > > -net nic,macadr=52.54.00.12.34.57 > > -net tap,script=./ifup.py,ifname=tap0 > > -hda /var/qemu/vm_images/F7image.img > > -boot c: -m 512 -vnc :2 -k de > > > > inside the image there is fedora 7, but a 32bit system. > > > > almost exact same as here except using 32 bit fedora rawhide > (development) guest running kernel 2.6.23-0.74.rc2.git1.fc8 > > > almost everything works (reboot hangs), but the system is extremely > > slow! the clock inside the system is extremely slow: every *virtual* > > second in the image is about two or more seconds in the *real* world. > > and I'm having the exact same issue here. The hardware clock works fine > (least from the output of /proc/driver/rtc and hwclock) but the system > time quickly falls behind in the guest, approx 0.5 secs for every 1 real > second. > > No combination of selecting different clocksources in the guest, > disabling CONFIG_NO_HZ, etc seemed to make any difference. And the fact > is my fc7 x86_64 install works just great so I doubt its the host. > > What I did notice though was ACPI wasn't being enabled by default for > the 32bit kernel with the message > > ACPI: no DMI BIOS year, acpi=force is required to enable ACPI > > and that the acpi_pm clocksource the x86_64 guest picked by default, > which worked fine, was missing. eg: > > 2.6.23-0.74.rc2.git1.fc8 i686 default boot: > > /sys/devices/system/clocksource/clocksource0/available_clocksource > pit jiffies tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource > pit > > 2.6.23-0.74.rc2.git1.fc8 i686 with acpi=force: > > /sys/devices/system/clocksource/clocksource0/available_clocksource > tsc acpi_pm pit jiffies > /sys/devices/system/clocksource/clocksource0/current_clocksource > tsc > > and now everything seems great, hardware and system time seem 1:1 > again. > > Attached is a diff of the dmesg from each boot. > > As to why this is... -- Matthew Kent <[EMAIL PROTECTED]> http://magoazul.com Linux version 2.6.23-0.74.rc2.git1.fc8 ([EMAIL PROTECTED]) (gcc version 4.1.2 20070723 (Red Hat 4.1.2-17)) #1 SMP Tue Aug 7 19:21:07 EDT 2007 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e8000 - 0010 (reserved) BIOS-e820: 0010 - 1fff (usable) BIOS-e820: 1fff - 2000 (ACPI data) BIOS-e820: fffc - 0001 (reserved) 0MB HIGHMEM available. 511MB LOWMEM available. Using x86 segment limits to approximate NX protection Entering add_active_range(0, 0, 131056) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 131056 HighMem131056 -> 131056 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 -> 131056 On node 0 totalpages: 131056 DMA zone: 56 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4040 pages, LIFO batch:0 Normal zone: 1735 pages used for memmap Normal zone: 125225 pages, LIFO batch:31 HighMem zone: 0 pages used for memmap Movable zone: 0 pages used for memmap DMI not present or invalid. Using APIC driver default ACPI: RSDP 000FA670, 0014 (r0 QEMU ) ACPI: RSDT 1FFF, 002C (r1 QEMU QEMURSDT1 QEMU1) ACPI: FACP 1FFF002C, 0074 (r1 QEMU QEMUFACP1 QEMU1) ACPI: DSDT 1FFF0100, 0832 (r1 BXPC BXDSDT1 INTL 20060912) ACPI: FACS 1FFF00C0, 0040 ACPI: APIC 1FFF0938, 0040 (r1 QEMU QEMUAPIC1 QEMU1) ACPI: no DMI BIOS year, acpi=force is required to enable ACPI ACPI: Disabling ACPI support Allocating PCI resources starting at 3000 (gap: 2000:dffc) swsusp: Registered nosave memory region: 0009f000 - 000a swsusp: Registered nosave memory region: 000a - 000e8000 swsusp: Registered nosave memory region: 000e8000 - 0010 Built 1 zonelists in Zone order. Total pages: 129265 Kernel command line: ro root=/dev/VolGroup00/LogVol00 console=tty0 console=ttyS0 debug Fo
Re: [kvm-devel] kvm very slow
the system is now MUCH faster! it boots really fast, i think, in the init-scripts there are much "sleep x", and every "x" were "2*x" in reality. other tasks are also much faster i'm happy now :-) although i cannot reboot ... (it hangs after halted), but that is another thread. Am Donnerstag, den 09.08.2007, 17:09 -0700 schrieb Matthew Kent: > [oops sorry. should have included the full dmesg from the bad boot and > cc'd the original poster] > > On Thu, 2007-09-08 at 16:23 -0700, Matthew Kent wrote: > > On Wed, 2007-01-08 at 07:22 +0200, Ulrich Schreiner wrote: > > > hi, > > > > > > im using a 64 bit fedora7 system with a quad-core processor to host > > > multiple virtual machines. > > > > > > > literally the exact same setup here > > > > > my current kernel is: > > > > > > Linux testserver 2.6.22.1-27.fc7 #1 SMP Tue Jul 17 17:19:58 EDT 2007 > > > x86_64 x86_64 x86_64 GNU/Linux > > > > > > (now there is a 2.6.22.1-33.fc7 to download, but i think it is not the > > > point here). > > > > > > > 2.6.22.1-41.fc7 x86_64 host > > > > > i installed > > > > > > kvm.x86_64: 31-1.fc8 > > > > kvm-33 > > > > > > > > because of a crash i reported as a bug with the older kvm module. > > > > > > this system starts a F7 image with the following command: > > > > > > /usr/bin/qemu-kvm > > > -net nic,macadr=52.54.00.12.34.57 > > > -net tap,script=./ifup.py,ifname=tap0 > > > -hda /var/qemu/vm_images/F7image.img > > > -boot c: -m 512 -vnc :2 -k de > > > > > > inside the image there is fedora 7, but a 32bit system. > > > > > > > almost exact same as here except using 32 bit fedora rawhide > > (development) guest running kernel 2.6.23-0.74.rc2.git1.fc8 > > > > > almost everything works (reboot hangs), but the system is extremely > > > slow! the clock inside the system is extremely slow: every *virtual* > > > second in the image is about two or more seconds in the *real* world. > > > > and I'm having the exact same issue here. The hardware clock works fine > > (least from the output of /proc/driver/rtc and hwclock) but the system > > time quickly falls behind in the guest, approx 0.5 secs for every 1 real > > second. > > > > No combination of selecting different clocksources in the guest, > > disabling CONFIG_NO_HZ, etc seemed to make any difference. And the fact > > is my fc7 x86_64 install works just great so I doubt its the host. > > > > What I did notice though was ACPI wasn't being enabled by default for > > the 32bit kernel with the message > > > > ACPI: no DMI BIOS year, acpi=force is required to enable ACPI > > > > and that the acpi_pm clocksource the x86_64 guest picked by default, > > which worked fine, was missing. eg: > > > > 2.6.23-0.74.rc2.git1.fc8 i686 default boot: > > > > /sys/devices/system/clocksource/clocksource0/available_clocksource > > pit jiffies tsc > > /sys/devices/system/clocksource/clocksource0/current_clocksource > > pit > > > > 2.6.23-0.74.rc2.git1.fc8 i686 with acpi=force: > > > > /sys/devices/system/clocksource/clocksource0/available_clocksource > > tsc acpi_pm pit jiffies > > /sys/devices/system/clocksource/clocksource0/current_clocksource > > tsc > > > > and now everything seems great, hardware and system time seem 1:1 > > again. > > > > Attached is a diff of the dmesg from each boot. > > > > As to why this is... - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm very slow
Matthew, your the hero of the day! with "acpi=force" in the guest the clock ticks correct. > ACPI: no DMI BIOS year, acpi=force is required to enable ACPI is it possible to use another bios where the acpi=force switch is not needed? or to fix the bios (i think kvm uses it's own bios, not the original qemu-bios) Am Donnerstag, den 09.08.2007, 17:09 -0700 schrieb Matthew Kent: > [oops sorry. should have included the full dmesg from the bad boot and > cc'd the original poster] > > On Thu, 2007-09-08 at 16:23 -0700, Matthew Kent wrote: > > On Wed, 2007-01-08 at 07:22 +0200, Ulrich Schreiner wrote: > > > hi, > > > > > > im using a 64 bit fedora7 system with a quad-core processor to host > > > multiple virtual machines. > > > > > > > literally the exact same setup here > > > > > my current kernel is: > > > > > > Linux testserver 2.6.22.1-27.fc7 #1 SMP Tue Jul 17 17:19:58 EDT 2007 > > > x86_64 x86_64 x86_64 GNU/Linux > > > > > > (now there is a 2.6.22.1-33.fc7 to download, but i think it is not the > > > point here). > > > > > > > 2.6.22.1-41.fc7 x86_64 host > > > > > i installed > > > > > > kvm.x86_64: 31-1.fc8 > > > > kvm-33 > > > > > > > > because of a crash i reported as a bug with the older kvm module. > > > > > > this system starts a F7 image with the following command: > > > > > > /usr/bin/qemu-kvm > > > -net nic,macadr=52.54.00.12.34.57 > > > -net tap,script=./ifup.py,ifname=tap0 > > > -hda /var/qemu/vm_images/F7image.img > > > -boot c: -m 512 -vnc :2 -k de > > > > > > inside the image there is fedora 7, but a 32bit system. > > > > > > > almost exact same as here except using 32 bit fedora rawhide > > (development) guest running kernel 2.6.23-0.74.rc2.git1.fc8 > > > > > almost everything works (reboot hangs), but the system is extremely > > > slow! the clock inside the system is extremely slow: every *virtual* > > > second in the image is about two or more seconds in the *real* world. > > > > and I'm having the exact same issue here. The hardware clock works fine > > (least from the output of /proc/driver/rtc and hwclock) but the system > > time quickly falls behind in the guest, approx 0.5 secs for every 1 real > > second. > > > > No combination of selecting different clocksources in the guest, > > disabling CONFIG_NO_HZ, etc seemed to make any difference. And the fact > > is my fc7 x86_64 install works just great so I doubt its the host. > > > > What I did notice though was ACPI wasn't being enabled by default for > > the 32bit kernel with the message > > > > ACPI: no DMI BIOS year, acpi=force is required to enable ACPI > > > > and that the acpi_pm clocksource the x86_64 guest picked by default, > > which worked fine, was missing. eg: > > > > 2.6.23-0.74.rc2.git1.fc8 i686 default boot: > > > > /sys/devices/system/clocksource/clocksource0/available_clocksource > > pit jiffies tsc > > /sys/devices/system/clocksource/clocksource0/current_clocksource > > pit > > > > 2.6.23-0.74.rc2.git1.fc8 i686 with acpi=force: > > > > /sys/devices/system/clocksource/clocksource0/available_clocksource > > tsc acpi_pm pit jiffies > > /sys/devices/system/clocksource/clocksource0/current_clocksource > > tsc > > > > and now everything seems great, hardware and system time seem 1:1 > > again. > > > > Attached is a diff of the dmesg from each boot. > > > > As to why this is... - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
Re: [kvm-devel] kvm very slow
Matthew Kent wrote: > ACPI: no DMI BIOS year, acpi=force is required to enable ACPI > > Well, we now have the bios in kvm-userspace.git (under bios/). If someone wants a go at adding DMI to the bios, it's waiting for you. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ ___ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
