kvm very slow

kvm very slow

[Ulrich Schreiner]

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
</usc>


-------------------------------------------------------------------------
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/

Re: kvm very slow

[Avi Kivity]

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/

Re: kvm very slow

[Ulrich Schreiner]

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 %MEM    TIME+  COMMAND
14917 root      20   0  332m  71m  66m S    6  0.9   1:17.05 qemu-kvm
14954 root      20   0 14552 1072  812 R    0  0.0   0:00.01 top
     1 root      20   0 10320  680  572 S    0  0.0   0:02.02 init

kvm_stat (snapshot):

kvm statistics

  exits        12254399   79079
  halt_exits     326543    4632
  invlpg              0       0
  io_exits      6539798   74320
  irq_exits       43523      29
  irq_window       4984       0
  mmio_exits    1319016       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/

Re: kvm very slow

[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 %MEM    TIME+  COMMAND
> 14917 root      20   0  332m  71m  66m S    6  0.9   1:17.05 qemu-kvm
> 14954 root      20   0 14552 1072  812 R    0  0.0   0:00.01 top
>      1 root      20   0 10320  680  572 S    0  0.0   0:02.02 init
>
> kvm_stat (snapshot):
>
> kvm statistics
>
>   exits        12254399   79079
>   halt_exits     326543    4632
>   invlpg              0       0
>   io_exits      6539798   74320
>   irq_exits       43523      29
>   irq_window       4984       0
>   mmio_exits    1319016       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/

Re: kvm very slow

[Ulrich Schreiner]

/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 %MEM    TIME+  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     0    0    0 S  0.0  0.0   0:00.00 migration/0
     3 root      34  19     0    0    0 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 %MEM    TIME+  COMMAND
>> 14917 root      20   0  332m  71m  66m S    6  0.9   1:17.05 qemu-kvm
>> 14954 root      20   0 14552 1072  812 R    0  0.0   0:00.01 top
>>      1 root      20   0 10320  680  572 S    0  0.0   0:02.02 init
>>
>> kvm_stat (snapshot):
>>
>> kvm statistics
>>
>>   exits        12254399   79079
>>   halt_exits     326543    4632
>>   invlpg              0       0
>>   io_exits      6539798   74320
>>   irq_exits       43523      29
>>   irq_window       4984       0
>>   mmio_exits    1319016       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/

Re: kvm very slow

[Ulrich Schreiner]

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 %MEM    TIME+  COMMAND
> > 14917 root      20   0  332m  71m  66m S    6  0.9   1:17.05 qemu-kvm
> > 14954 root      20   0 14552 1072  812 R    0  0.0   0:00.01 top
> >      1 root      20   0 10320  680  572 S    0  0.0   0:02.02 init
> >
> > kvm_stat (snapshot):
> >
> > kvm statistics
> >
> >   exits        12254399   79079
> >   halt_exits     326543    4632
> >   invlpg              0       0
> >   io_exits      6539798   74320
> >   irq_exits       43523      29
> >   irq_window       4984       0
> >   mmio_exits    1319016       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/

Re: kvm very slow

[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 %MEM    TIME+
>COMMAND
>> > 14917 root      20   0  332m  71m  66m S    6  0.9   1:17.05 qemu-
>kvm
>> > 14954 root      20   0 14552 1072  812 R    0  0.0   0:00.01 top
>> >      1 root      20   0 10320  680  572 S    0  0.0   0:02.02 init
>> >
>> > kvm_stat (snapshot):
>> >
>> > kvm statistics
>> >
>> >   exits        12254399   79079
>> >   halt_exits     326543    4632
>> >   invlpg              0       0
>> >   io_exits      6539798   74320
>> >   irq_exits       43523      29
>> >   irq_window       4984       0
>> >   mmio_exits    1319016       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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
>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/

Re: kvm very slow

[Ulrich Schreiner]

today morning i compiled kvm-33 and the output of kvm-stat is much
better now (guest in idle):

kvm statistics

 efer_reload  10944273    6504
 exits        13722688    6967
 halt_exits    1084344     935
 invlpg              0       0
 io_exits      7668914    5070
 irq_exits       27886       2
 irq_window      11477       1
 light_exits   2778416     462
 mmio_exits    2153709     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 %MEM    TIME+
> >COMMAND
> >> > 14917 root      20   0  332m  71m  66m S    6  0.9   1:17.05 qemu-
> >kvm
> >> > 14954 root      20   0 14552 1072  812 R    0  0.0   0:00.01 top
> >> >      1 root      20   0 10320  680  572 S    0  0.0   0:02.02 init
> >> >
> >> > kvm_stat (snapshot):
> >> >
> >> > kvm statistics
> >> >
> >> >   exits        12254399   79079
> >> >   halt_exits     326543    4632
> >> >   invlpg              0       0
> >> >   io_exits      6539798   74320
> >> >   irq_exits       43523      29
> >> >   irq_window       4984       0
> >> >   mmio_exits    1319016       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-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> >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/

Re: kvm very slow

[Luca]

On 8/7/07, Ulrich Schreiner <ulrich.schreiner-sZDnKEZIvs8b1SvskN2V4Q@public.gmane.org> 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/

Re: kvm very slow

[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  10944273    6504
> exits        13722688    6967
> halt_exits    1084344     935
> invlpg              0       0
> io_exits      7668914    5070
> irq_exits       27886       2
> irq_window      11477       1
> light_exits   2778416     462
> mmio_exits    2153709     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/

Re: kvm very slow

[Luca]

On 8/7/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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/

Re: kvm very slow

[Dor Laor]

>> 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/

Re: kvm very slow

[Ulrich Schreiner]

> 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).

</usc>


-------------------------------------------------------------------------
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/

Re: kvm very slow

[Dong, Eddie]

kvm-devel-bounces-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 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/

Re: kvm very slow

[Dor Laor]

>>> 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/

Re: kvm very slow

[Luca Tettamanti]

Il Tue, Aug 07, 2007 at 02:08:08PM +0200, Luca ha scritto: 
> On 8/7/07, Dor Laor <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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 <pty.h>
 #include <malloc.h>
 #include <linux/rtc.h>
+#include <linux/hpet.h>
 #include <linux/ppdev.h>
 #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)
            "-tdf            inject timer interrupts that got lost\n"
 #if defined(__linux__)
            "-no-rtc         don't use /dev/rtc for timer alarm (do use gettimeofday)\n"
+           "-use-rtc        use /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/

Re: kvm very slow

[Ulrich Schreiner]

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. 

</usc>

ps: the line

"-use-rtc        use /dev/hpet (HPET) for timer alarm (do use
gettimeofday)\n"


should be

"-use-hpet        use /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 <dor.laor-atKUWr5tajBWk0Htik3J/w@public.gmane.org> 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 <pty.h>
>  #include <malloc.h>
>  #include <linux/rtc.h>
> +#include <linux/hpet.h>
>  #include <linux/ppdev.h>
>  #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)
>             "-tdf            inject timer interrupts that got lost\n"
>  #if defined(__linux__)
>             "-no-rtc         don't use /dev/rtc for timer alarm (do use gettimeofday)\n"
> +           "-use-rtc        use /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


-------------------------------------------------------------------------
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/

Re: kvm very slow

[Ulrich Schreiner]

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?

</usc>

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  10944273    6504
> > exits        13722688    6967
> > halt_exits    1084344     935
> > invlpg              0       0
> > io_exits      7668914    5070
> > irq_exits       27886       2
> > irq_window      11477       1
> > light_exits   2778416     462
> > mmio_exits    2153709     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/

Re: kvm very slow

[Matthew Kent]

[-- Attachment #1: Type: text/plain, Size: 2571 bytes --]

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 <mkent-rTVjrLRGJfNWk0Htik3J/w@public.gmane.org>
http://magoazul.com

[-- Attachment #2: acpi.diff --]
[-- Type: text/x-patch, Size: 9260 bytes --]

--- dmesg.f7_32bit_default	2007-08-09 16:00:00.000000000 -0700
+++ dmesg.f7_32bit_forced_acpi	2007-08-09 15:59:55.000000000 -0700
@@ -34,21 +34,30 @@
 ACPI: FACS 1FFF00C0, 0040
 ACPI: APIC 1FFF0938, 0040 (r1 QEMU   QEMUAPIC        1 QEMU        1)
 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 0xfee00000
+ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
+Processor #0 6:2 APIC version 17
+ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
+IOAPIC[0]: apic_id 1, version 17, address 0xfec00000, 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 30000000 (gap: 20000000:dffc0000)
 swsusp: Registered nosave memory region: 000000000009f000 - 00000000000a0000
 swsusp: Registered nosave memory region: 00000000000a0000 - 00000000000e8000
 swsusp: Registered nosave memory region: 00000000000e8000 - 0000000000100000
 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 ffffb000 (fee00000)
+mapped IOAPIC to ffffa000 (fec00000)
 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 : 0xc0400000 - 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 QEMU Virtual CPU version 0.9.0 stepping 03
-SMP motherboard not detected.
+Total of 1 processors activated (9622.99 BogoMIPS).
+ENABLING IO-APIC IRQs
+..TIMER: vector=0x31 apic1=0 pin1=0 apic2=-1 pin2=-1
+APIC calibration not consistent with PM Timer: 199ms instead of 100ms
+APIC delta adjusted to PM-Timer: 6249985 (12499675)
 Brought up 1 CPUs
 sizeof(vma)=84 bytes
 sizeof(page)=56 bytes
@@ -106,25 +120,36 @@
 khelper used greatest stack depth: 3160 bytes left
 Booting paravirtualized kernel on bare hardware
 khelper used greatest stack depth: 3084 bytes left
-Time: 22:48:42  Date: 07/09/107
+Time: 22:55:44  Date: 07/09/107
 NET: Registered protocol family 16
+ACPI: bus type pci registered
 PCI: PCI BIOS revision 2.10 entry at 0xfa130, last bus=0
 PCI: Using configuration type 1
 Setting up standard PCI resources
-khelper used greatest stack depth: 2928 bytes left
-ACPI: Interpreter disabled.
-Linux Plug and Play Support v0.97 (c) Adam Belay
-pnp: PnP ACPI: disabled
-usbcore: registered new interface driver usbfs
-usbcore: registered new interface driver hub
-usbcore: registered new device driver usb
-PCI: Probing PCI hardware
-PCI: Probing PCI hardware (bus 00)
+ACPI: Interpreter enabled
+ACPI: (supports)
+ACPI: Using IOAPIC for interrupt routing
+khelper used greatest stack depth: 2944 bytes left
+ACPI: PCI Root Bridge [PCI0] (0000:00)
 * Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
 * this clock source is slow. Consider trying other clock sources
 PCI quirk: region b000-b03f claimed by PIIX4 ACPI
 PCI quirk: region b100-b10f claimed by PIIX4 SMB
-PCI: Using IRQ router PIIX/ICH [8086/7000] at 0000:00:01.0
+ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
+ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11 12)
+ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *9 10 11 12)
+ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11 12)
+ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 *9 10 11 12)
+Linux Plug and Play Support v0.97 (c) Adam Belay
+pnp: PnP ACPI init
+ACPI: bus type pnp registered
+pnp: PnP ACPI: found 6 devices
+ACPI: ACPI bus type pnp unregistered
+usbcore: registered new interface driver usbfs
+usbcore: registered new interface driver hub
+usbcore: registered new device driver usb
+PCI: Using ACPI for IRQ routing
+PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
 NetLabel: Initializing
 NetLabel:  domain hash size = 128
 NetLabel:  protocols = UNLABELED CIPSOv4
@@ -139,10 +164,10 @@
 checking if image is initramfs... it is
 Freeing initrd memory: 3801k freed
 apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
+apm: overridden by ACPI.
 audit: initializing netlink socket (disabled)
-audit(1186699721.596:1): initialized
+audit(1186700143.557:1): initialized
 Total HugeTLB memory allocated, 0
-khelper used greatest stack depth: 2888 bytes left
 VFS: Disk quotas dquot_6.5.1
 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
 SELinux:  Registering netfilter hooks
@@ -159,17 +184,19 @@
 Activating ISA DMA hang workarounds.
 Boot video device is 0000:00:02.0
 pci_hotplug: PCI Hot Plug PCI Core version: 0.5
-khelper used greatest stack depth: 2860 bytes left
 isapnp: Scanning for PnP cards...
+Switched to high resolution mode on CPU 0
 isapnp: No Plug & Play device found
 Generic RTC Driver v1.07
 Non-volatile memory driver v1.2
 Linux agpgart interface v0.102
 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
 serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16450
+00:05: ttyS0 at I/O 0x3f8 (irq = 4) is a 16450
 RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
+khelper used greatest stack depth: 2784 bytes left
 input: Macintosh mouse button emulation as /class/input/input0
-PNP: No PS/2 controller found. Probing ports directly.
+PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
 serio: i8042 KBD port at 0x60,0x64 irq 1
 serio: i8042 AUX port at 0x60,0x64 irq 12
 mice: PS/2 mouse device common for all mice
@@ -182,17 +209,15 @@
 NET: Registered protocol family 1
 NET: Registered protocol family 17
 Using IPI No-Shortcut mode
-  Magic number: 3:809:855
+  Magic number: 3:912:956
 drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
 Freeing unused kernel memory: 568k freed
 Write protecting the kernel read-only data: 916k
-Clocksource tsc unstable (delta = 542506452 ns)
-Time: pit clocksource has been installed.
+input: ImExPS/2 Generic Explorer Mouse as /class/input/input2
 USB Universal Host Controller Interface driver v3.0
-insmod used greatest stack depth: 2492 bytes left
+insmod used greatest stack depth: 2340 bytes left
 ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
-insmod used greatest stack depth: 2400 bytes left
-input: ImExPS/2 Generic Explorer Mouse as /class/input/input2
+insmod used greatest stack depth: 2312 bytes left
 SCSI subsystem initialized
 libata version 2.21 loaded.
 ata_piix 0000:00:01.1: version 2.11
@@ -220,28 +245,25 @@
 scsi 1:0:0:0: CD-ROM            QEMU     QEMU CD-ROM      0.9. PQ: 0 ANSI: 5
 insmod used greatest stack depth: 876 bytes left
 device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
-EXT3-fs: INFO: recovery required on readonly filesystem.
-EXT3-fs: write access will be enabled during recovery.
 kjournald starting.  Commit interval 5 seconds
-EXT3-fs: dm-0: orphan cleanup on readonly fs
-ext3_orphan_cleanup: deleting unreferenced inode 2254377
-EXT3-fs: dm-0: 1 orphan inode deleted
-EXT3-fs: recovery complete.
 EXT3-fs: mounted filesystem with ordered data mode.
 SELinux:  Disabled at runtime.
 SELinux:  Unregistering netfilter hooks
-audit(1186699726.899:2): selinux=0 auid=4294967295
+audit(1186700148.939:2): selinux=0 auid=4294967295
 sd 0:0:0:0: Attached scsi generic sg0 type 0
 scsi 1:0:0:0: Attached scsi generic sg1 type 5
 sr0: scsi3-mmc drive: 4x/4x xa/form2 tray
 Uniform CD-ROM driver Revision: 3.20
 sr 1:0:0:0: Attached scsi CD-ROM sr0
-ne2k-pci.c:v1.03 9/22/2003 D. Becker/P. Gortmaker
-PCI: setting IRQ 11 as level-triggered
-PCI: Found IRQ 11 for device 0000:00:03.0
-eth0: RealTek RTL-8029 found at 0xc100, IRQ 11, 52:54:00:12:34:56.
 piix4_smbus 0000:00:01.3: Found 0000:00:01.3 device
+ne2k-pci.c:v1.03 9/22/2003 D. Becker/P. Gortmaker
+ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 10
+ACPI: PCI Interrupt 0000:00:03.0[A] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10
+eth0: RealTek RTL-8029 found at 0xc100, IRQ 10, 52:54:00:12:34:56.
+parport_pc 00:04: reported by Plug and Play ACPI
+parport0: PC-style at 0x378, irq 7 [PCSPP,EPP]
 FDC 0 is a S82078B
+No dock devices found.
 device-mapper: multipath: version 1.0.5 loaded
 EXT3 FS on dm-0, internal journal
 kjournald starting.  Commit interval 5 seconds

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: kvm very slow

[Matthew Kent]

[-- Attachment #1: Type: text/plain, Size: 2892 bytes --]

[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 <mkent-rTVjrLRGJfNWk0Htik3J/w@public.gmane.org>
http://magoazul.com

[-- Attachment #2: dmesg.f7_32bit_default --]
[-- Type: text/plain, Size: 11434 bytes --]

Linux version 2.6.23-0.74.rc2.git1.fc8 (kojibuilder-fbpyxXtnJUxHcw7WmXvZTaw4yJhunYrG28t4la5Gatg@public.gmane.org) (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: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e8000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001fff0000 (usable)
 BIOS-e820: 000000001fff0000 - 0000000020000000 (ACPI data)
 BIOS-e820: 00000000fffc0000 - 0000000100000000 (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
  HighMem    131056 ->   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 1FFF0000, 002C (r1 QEMU   QEMURSDT        1 QEMU        1)
ACPI: FACP 1FFF002C, 0074 (r1 QEMU   QEMUFACP        1 QEMU        1)
ACPI: DSDT 1FFF0100, 0832 (r1   BXPC   BXDSDT        1 INTL 20060912)
ACPI: FACS 1FFF00C0, 0040
ACPI: APIC 1FFF0938, 0040 (r1 QEMU   QEMUAPIC        1 QEMU        1)
ACPI: no DMI BIOS year, acpi=force is required to enable ACPI
ACPI: Disabling ACPI support
Allocating PCI resources starting at 30000000 (gap: 20000000:dffc0000)
swsusp: Registered nosave memory region: 000000000009f000 - 00000000000a0000
swsusp: Registered nosave memory region: 00000000000a0000 - 00000000000e8000
swsusp: Registered nosave memory region: 00000000000e8000 - 0000000000100000
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!
mapped APIC to ffffb000 (fee00000)
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.
Console: colour VGA+ 80x25
console [tty0] enabled
console [ttyS0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES:    8
... MAX_LOCK_DEPTH:          30
... MAX_LOCKDEP_KEYS:        2048
... CLASSHASH_SIZE:           1024
... MAX_LOCKDEP_ENTRIES:     8192
... MAX_LOCKDEP_CHAINS:      16384
... CHAINHASH_SIZE:          8192
 memory used by lock dependency info: 1024 kB
 per task-struct memory footprint: 1680 bytes
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 504980k/524224k available (2241k kernel code, 18676k reserved, 1216k data, 568k init, 0k highmem)
virtual kernel memory layout:
    fixmap  : 0xffc53000 - 0xfffff000   (3760 kB)
    pkmap   : 0xff800000 - 0xffc00000   (4096 kB)
    vmalloc : 0xe0800000 - 0xff7fe000   ( 495 MB)
    lowmem  : 0xc0000000 - 0xdfff0000   ( 511 MB)
      .init : 0xc0766000 - 0xc07f4000   ( 568 kB)
      .data : 0xc063074d - 0xc0760a44   (1216 kB)
      .text : 0xc0400000 - 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)
Security Framework v1.0.0 initialized
SELinux:  Initializing.
SELinux:  Starting in permissive mode
selinux_register_security:  Registering secondary module capability
Capability LSM initialized as secondary
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 078bfbfd 2191abfd 00000000 00000000 00000001 00000000 00000000 00000000
CPU: L1 I cache: 8K
CPU: L2 cache: 128K
CPU: After all inits, caps: 078bf3fd 2191abfd 00000000 00000040 00000001 00000000 00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Compat vDSO mapped to ffffe000.
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 12k freed
CPU0: Intel QEMU Virtual CPU version 0.9.0 stepping 03
SMP motherboard not detected.
Brought up 1 CPUs
sizeof(vma)=84 bytes
sizeof(page)=56 bytes
sizeof(inode)=604 bytes
sizeof(dentry)=160 bytes
sizeof(ext3inode)=856 bytes
sizeof(buffer_head)=56 bytes
sizeof(skbuff)=180 bytes
sizeof(task_struct)=3376 bytes
khelper used greatest stack depth: 3160 bytes left
Booting paravirtualized kernel on bare hardware
khelper used greatest stack depth: 3084 bytes left
Time: 22:48:42  Date: 07/09/107
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfa130, last bus=0
PCI: Using configuration type 1
Setting up standard PCI resources
khelper used greatest stack depth: 2928 bytes left
ACPI: Interpreter disabled.
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI: disabled
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
* Found PM-Timer Bug on the chipset. Due to workarounds for a bug,
* this clock source is slow. Consider trying other clock sources
PCI quirk: region b000-b03f claimed by PIIX4 ACPI
PCI quirk: region b100-b10f claimed by PIIX4 SMB
PCI: Using IRQ router PIIX/ICH [8086/7000] at 0000:00:01.0
NetLabel: Initializing
NetLabel:  domain hash size = 128
NetLabel:  protocols = UNLABELED CIPSOv4
NetLabel:  unlabeled traffic allowed by default
Time: tsc clocksource has been installed.
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 7, 655360 bytes)
TCP bind hash table entries: 16384 (order: 7, 589824 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
checking if image is initramfs... it is
Freeing initrd memory: 3801k freed
apm: BIOS version 1.2 Flags 0x03 (Driver version 1.16ac)
audit: initializing netlink socket (disabled)
audit(1186699721.596:1): initialized
Total HugeTLB memory allocated, 0
khelper used greatest stack depth: 2888 bytes left
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
SELinux:  Registering netfilter hooks
ksign: Installing public key data
Loading keyring
- Added public key 5890683852E154E7
- User ID: Red Hat, Inc. (Kernel Module GPG key)
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Limiting direct PCI/PCI transfers.
PCI: PIIX3: Enabling Passive Release on 0000:00:01.0
Activating ISA DMA hang workarounds.
Boot video device is 0000:00:02.0
pci_hotplug: PCI Hot Plug PCI Core version: 0.5
khelper used greatest stack depth: 2860 bytes left
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
Generic RTC Driver v1.07
Non-volatile memory driver v1.2
Linux agpgart interface v0.102
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16450
RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
input: Macintosh mouse button emulation as /class/input/input0
PNP: No PS/2 controller found. Probing ports directly.
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input1
usbcore: registered new interface driver hiddev
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
TCP cubic registered
Initializing XFRM netlink socket
NET: Registered protocol family 1
NET: Registered protocol family 17
Using IPI No-Shortcut mode
  Magic number: 3:809:855
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
Freeing unused kernel memory: 568k freed
Write protecting the kernel read-only data: 916k
Clocksource tsc unstable (delta = 542506452 ns)
Time: pit clocksource has been installed.
USB Universal Host Controller Interface driver v3.0
insmod used greatest stack depth: 2492 bytes left
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
insmod used greatest stack depth: 2400 bytes left
input: ImExPS/2 Generic Explorer Mouse as /class/input/input2
SCSI subsystem initialized
libata version 2.21 loaded.
ata_piix 0000:00:01.1: version 2.11
PCI: Setting latency timer of device 0000:00:01.1 to 64
scsi0 : ata_piix
scsi1 : ata_piix
ata1: PATA max MWDMA2 cmd 0x000101f0 ctl 0x000103f6 bmdma 0x0001c000 irq 14
ata2: PATA max MWDMA2 cmd 0x00010170 ctl 0x00010376 bmdma 0x0001c008 irq 15
ata1.00: ATA-7: QEMU HARDDISK, 0.9.0, max UDMA/100
ata1.00: 20971520 sectors, multi 16: LBA48 
ata1.00: configured for MWDMA2
ata2.00: ATAPI: QEMU CD-ROM, 0.9.0, max UDMA/100
ata2.00: configured for MWDMA2
scsi 0:0:0:0: Direct-Access     ATA      QEMU HARDDISK    0.9. PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] 20971520 512-byte hardware sectors (10737 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
sd 0:0:0:0: [sda] 20971520 512-byte hardware sectors (10737 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
 sda: sda1 sda2
sd 0:0:0:0: [sda] Attached SCSI disk
scsi 1:0:0:0: CD-ROM            QEMU     QEMU CD-ROM      0.9. PQ: 0 ANSI: 5
insmod used greatest stack depth: 876 bytes left
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: dm-0: orphan cleanup on readonly fs
ext3_orphan_cleanup: deleting unreferenced inode 2254377
EXT3-fs: dm-0: 1 orphan inode deleted
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
SELinux:  Disabled at runtime.
SELinux:  Unregistering netfilter hooks
audit(1186699726.899:2): selinux=0 auid=4294967295
sd 0:0:0:0: Attached scsi generic sg0 type 0
scsi 1:0:0:0: Attached scsi generic sg1 type 5
sr0: scsi3-mmc drive: 4x/4x xa/form2 tray
Uniform CD-ROM driver Revision: 3.20
sr 1:0:0:0: Attached scsi CD-ROM sr0
ne2k-pci.c:v1.03 9/22/2003 D. Becker/P. Gortmaker
PCI: setting IRQ 11 as level-triggered
PCI: Found IRQ 11 for device 0000:00:03.0
eth0: RealTek RTL-8029 found at 0xc100, IRQ 11, 52:54:00:12:34:56.
piix4_smbus 0000:00:01.3: Found 0000:00:01.3 device
FDC 0 is a S82078B
device-mapper: multipath: version 1.0.5 loaded
EXT3 FS on dm-0, internal journal
kjournald starting.  Commit interval 5 seconds
EXT3 FS on sda1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Adding 1048568k swap on /dev/VolGroup00/LogVol01.  Priority:-1 extents:1 across:1048568k

[-- Attachment #3: Type: text/plain, Size: 315 bytes --]

-------------------------------------------------------------------------
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/

[-- Attachment #4: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: kvm very slow

[Ulrich Schreiner]

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/

Re: kvm very slow

[Ulrich Schreiner]

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/

Re: kvm very slow

[Avi Kivity]

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/