* qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
@ 2011-01-06 7:48 Nikola Ciprich
2011-01-06 9:03 ` Stefan Hajnoczi
2011-01-06 9:08 ` Avi Kivity
0 siblings, 2 replies; 29+ messages in thread
From: Nikola Ciprich @ 2011-01-06 7:48 UTC (permalink / raw)
To: KVM list; +Cc: nikola.ciprich
Hi,
I'd like to ask for advice with following problem.
I have windows 2008 terminal server guest running on 2.6.36 x86_64
host (kvm 0.13.0).
guest has 4GB of RAM, 40GB storage on top of LVM volume and two cores.
So far everything was running fine, but during periodic maintenance
I wanted to force chkdisk after reboot.
So windows started checking disk integrity, but the problem is, that
it's waaay too slow - after ~12 hours, it's still running and seeems
like it'll take ages to finish.
Both CPU cores seem to be fully loaded.
Is there some way I could check why it's taking so long, and fix
it eventually?
can I use kvm_trace to achieve this task? how?
I'll be very gratefull for any help...
with best regards
nik
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-06 7:48 qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow Nikola Ciprich
@ 2011-01-06 9:03 ` Stefan Hajnoczi
2011-01-06 9:06 ` Nikola Ciprich
2011-01-06 9:08 ` Avi Kivity
1 sibling, 1 reply; 29+ messages in thread
From: Stefan Hajnoczi @ 2011-01-06 9:03 UTC (permalink / raw)
To: Nikola Ciprich; +Cc: KVM list, nikola.ciprich
On Thu, Jan 6, 2011 at 7:48 AM, Nikola Ciprich <extmaillist@linuxbox.cz> wrote:
> So windows started checking disk integrity, but the problem is, that
> it's waaay too slow - after ~12 hours, it's still running and seeems
> like it'll take ages to finish.
Please post your KVM command-line.
Have you run storage benchmarks on the host to check what sort of
maximum I/O performance you can expect? Do you have a RAID setup
underneath LVM?
Stefan
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-06 9:03 ` Stefan Hajnoczi
@ 2011-01-06 9:06 ` Nikola Ciprich
0 siblings, 0 replies; 29+ messages in thread
From: Nikola Ciprich @ 2011-01-06 9:06 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: KVM list, nikola.ciprich
Hello Stefan!
> Please post your KVM command-line.
/usr/bin/qemu-kvm -S -M pc-0.13 -enable-kvm -m 4096 -smp 2,sockets=2,cores=1,threads=1 -name vmwts02 -uuid 1e501300-dc48-11df-a690-00304834195b -nodefconfig -nodefaults -chardev socket,id=monitor,path=/var/lib/libvirt/qemu/vmwts02.monitor,server,nowait -mon chardev=monitor,mode=readline -rtc base=localtime -boot c -drive file=/dev/vgshared/vmwts02-1,if=none,id=drive-ide0-0-0,format=raw -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=22,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=00:16:3e:61:01:00,bus=pci.0,addr=0x3 -usb -vnc 0.0.0.0:30801 -vga cirrus -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4
I see I could disable cache for storage, but I don't want to kill
fsck now just to test if it helps (and I guess it shouldn't make
such a difference).
> Have you run storage benchmarks on the host to check what sort of
> maximum I/O performance you can expect? Do you have a RAID setup
> underneath LVM?
Not for windows, but in general it is running quite fast, only the chkdsk
seems to be bad. In other VMs (linux), I'm achieving write speeds >40MB/s.
Storage configuration is a bit comples, it's DRBD replicated storage,
on top of it sits clustered LVM and KVMS use logical volumes on top of it.
but as I said, overall performance is OK.
>
> Stefan
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-06 7:48 qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow Nikola Ciprich
2011-01-06 9:03 ` Stefan Hajnoczi
@ 2011-01-06 9:08 ` Avi Kivity
2011-01-06 9:20 ` Nikola Ciprich
1 sibling, 1 reply; 29+ messages in thread
From: Avi Kivity @ 2011-01-06 9:08 UTC (permalink / raw)
To: Nikola Ciprich; +Cc: KVM list, nikola.ciprich
On 01/06/2011 09:48 AM, Nikola Ciprich wrote:
> Hi,
> I'd like to ask for advice with following problem.
> I have windows 2008 terminal server guest running on 2.6.36 x86_64
> host (kvm 0.13.0).
> guest has 4GB of RAM, 40GB storage on top of LVM volume and two cores.
> So far everything was running fine, but during periodic maintenance
> I wanted to force chkdisk after reboot.
> So windows started checking disk integrity, but the problem is, that
> it's waaay too slow - after ~12 hours, it's still running and seeems
> like it'll take ages to finish.
> Both CPU cores seem to be fully loaded.
> Is there some way I could check why it's taking so long, and fix
> it eventually?
> can I use kvm_trace to achieve this task? how?
Let's start with a few 'kvm_stat -1' snapshots while this is going on.
http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=blob_plain;f=kvm/kvm_stat;hb=HEAD
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-06 9:08 ` Avi Kivity
@ 2011-01-06 9:20 ` Nikola Ciprich
2011-01-06 9:27 ` Avi Kivity
0 siblings, 1 reply; 29+ messages in thread
From: Nikola Ciprich @ 2011-01-06 9:20 UTC (permalink / raw)
To: Avi Kivity; +Cc: KVM list, nikola.ciprich
Hello Avi!
On Thu, Jan 06, 2011 at 11:08:32AM +0200, Avi Kivity wrote:
> Let's start with a few 'kvm_stat -1' snapshots while this is going on.
here it is, but note that there are few more machines running on this host.
but they're almost idle in contrast to this windows one, so I hope it's not problem.
kvm_ack_irq 299 290
kvm_age_page 71 69
kvm_apic 1126 1087
kvm_apic_accept_irq 453 438
kvm_apic_ipi 236 228
kvm_cpuid 0 0
kvm_cr 780 772
kvm_emulate_insn 46181 44982
kvm_entry 55012 53867
kvm_exit 55182 53884
kvm_exit(APIC_ACCESS) 3 0
kvm_exit(CPUID) 3 0
kvm_exit(CR_ACCESS) 784 772
kvm_exit(DR_ACCESS) 3 0
kvm_exit(EPT_MISCONFIG) 4 0
kvm_exit(EPT_VIOLATION) 4 0
kvm_exit(EXCEPTION_NMI) 50194 49039
kvm_exit(EXTERNAL_INTERRUPT) 2314 2213
kvm_exit(HLT) 260 248
kvm_exit(INVALID_STATE) 3 0
kvm_exit(INVLPG) 103 98
kvm_exit(IO_INSTRUCTION) 1538 1534
kvm_exit(MCE_DURING_VMENTRY) 5 0
kvm_exit(MONITOR_INSTRUCTION) 3 0
kvm_exit(MSR_READ) 5 0
kvm_exit(MSR_WRITE) 4 0
kvm_exit(MWAIT_INSTRUCTION) 3 0
kvm_exit(NMI_WINDOW) 4 0
kvm_exit(PAUSE_INSTRUCTION) 4 0
kvm_exit(PENDING_INTERRUPT) 12 7
kvm_exit(RDPMC) 4 0
kvm_exit(RDTSC) 4 0
kvm_exit(TASK_SWITCH) 3 0
kvm_exit(TPR_BELOW_THRESHOLD) 6 2
kvm_exit(TRIPLE_FAULT) 5 0
kvm_exit(VMCALL) 4 0
kvm_exit(VMCLEAR) 3 0
kvm_exit(VMLAUNCH) 3 0
kvm_exit(VMOFF) 4 0
kvm_exit(VMON) 3 0
kvm_exit(VMPTRLD) 4 0
kvm_exit(VMPTRST) 4 0
kvm_exit(VMREAD) 5 0
kvm_exit(VMRESUME) 3 0
kvm_exit(VMWRITE) 4 0
kvm_exit(WBINVD) 3 0
kvm_exit(XSETBV) 4 0
kvm_fpu 247 243
kvm_hv_hypercall 0 0
kvm_hypercall 0 0
kvm_inj_exception 0 0
kvm_inj_virq 514 500
kvm_invlpga 0 0
kvm_ioapic_set_irq 363 353
kvm_mmio 67725 65974
kvm_msi_set_irq 0 0
kvm_msr 0 0
kvm_nested_intercepts 0 0
kvm_nested_intr_vmexit 0 0
kvm_nested_vmexit 0 0
kvm_nested_vmexit_inject 0 0
kvm_nested_vmrun 0 0
kvm_page_fault 50200 48785
kvm_pic_set_irq 363 353
kvm_pio 1541 1541
kvm_set_irq 363 353
kvm_skinit 0 0
>
> http://git.kernel.org/?p=virt/kvm/qemu-kvm.git;a=blob_plain;f=kvm/kvm_stat;hb=HEAD
>
> --
> error compiling committee.c: too many arguments to function
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-06 9:20 ` Nikola Ciprich
@ 2011-01-06 9:27 ` Avi Kivity
2011-01-06 9:30 ` Avi Kivity
2011-01-06 9:42 ` Nikola Ciprich
0 siblings, 2 replies; 29+ messages in thread
From: Avi Kivity @ 2011-01-06 9:27 UTC (permalink / raw)
To: Nikola Ciprich; +Cc: KVM list, nikola.ciprich
On 01/06/2011 11:20 AM, Nikola Ciprich wrote:
> Hello Avi!
> On Thu, Jan 06, 2011 at 11:08:32AM +0200, Avi Kivity wrote:
> > Let's start with a few 'kvm_stat -1' snapshots while this is going on.
>
> here it is, but note that there are few more machines running on this host.
> but they're almost idle in contrast to this windows one, so I hope it's not problem.
> kvm_cr 780 772
> kvm_emulate_insn 46181 44982
> kvm_entry 55012 53867
> kvm_exit 55182 53884
It's emulating quite a bit. Let's see why.
- install udis86 and udis86-devel
- build and install
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git
- run trace-cmd record -e kvm -b 100000 -P pid1 -P pid2, ctrl-C after a
few seconds (pid1/pid2 are thread ids from 'info cpus' of the bad guest,
plus the pid of the qemu process itself)
- post the resulting trace.dat somewhere
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-06 9:27 ` Avi Kivity
@ 2011-01-06 9:30 ` Avi Kivity
2011-01-06 9:42 ` Nikola Ciprich
1 sibling, 0 replies; 29+ messages in thread
From: Avi Kivity @ 2011-01-06 9:30 UTC (permalink / raw)
To: Nikola Ciprich; +Cc: KVM list, nikola.ciprich
On 01/06/2011 11:27 AM, Avi Kivity wrote:
> On 01/06/2011 11:20 AM, Nikola Ciprich wrote:
>> Hello Avi!
>> On Thu, Jan 06, 2011 at 11:08:32AM +0200, Avi Kivity wrote:
>> > Let's start with a few 'kvm_stat -1' snapshots while this is going
>> on.
>>
>> here it is, but note that there are few more machines running on this
>> host.
>> but they're almost idle in contrast to this windows one, so I hope
>> it's not problem.
>
>> kvm_cr 780 772
>> kvm_emulate_insn 46181 44982
>> kvm_entry 55012 53867
>> kvm_exit 55182 53884
>
> It's emulating quite a bit. Let's see why.
>
> - install udis86 and udis86-devel
> - build and install
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/trace-cmd.git
> - run trace-cmd record -e kvm -b 100000 -P pid1 -P pid2, ctrl-C after
> a few seconds (pid1/pid2 are thread ids from 'info cpus' of the bad
> guest, plus the pid of the qemu process itself)
> - post the resulting trace.dat somewhere
>
btw, that 100000 is 400MB of nonswappable kernel memory per cpu, so if
you have lots of cpus and not enough memory, adjust it down.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-06 9:27 ` Avi Kivity
2011-01-06 9:30 ` Avi Kivity
@ 2011-01-06 9:42 ` Nikola Ciprich
2011-01-06 10:19 ` Avi Kivity
1 sibling, 1 reply; 29+ messages in thread
From: Nikola Ciprich @ 2011-01-06 9:42 UTC (permalink / raw)
To: Avi Kivity; +Cc: KVM list, nikola.ciprich
> - run trace-cmd record -e kvm -b 100000 -P pid1 -P pid2, ctrl-C after a
seems like it's not possible to specify multiple pids, so
I've run 4 commands in parallel. Also I can't get monitor information
since vm is started using libvirt, so I've just used all machine's qemu-kvm
pids..
hope it's OK
here's the trace:
http://nelide.cz/downloads/nik/trace.tar.bz2
n.
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-06 9:42 ` Nikola Ciprich
@ 2011-01-06 10:19 ` Avi Kivity
2011-01-06 10:25 ` Nikola Ciprich
` (2 more replies)
0 siblings, 3 replies; 29+ messages in thread
From: Avi Kivity @ 2011-01-06 10:19 UTC (permalink / raw)
To: Nikola Ciprich; +Cc: KVM list, nikola.ciprich, Daniel P. Berrange
On 01/06/2011 11:42 AM, Nikola Ciprich wrote:
> > - run trace-cmd record -e kvm -b 100000 -P pid1 -P pid2, ctrl-C after a
> seems like it's not possible to specify multiple pids, so
Did you get 'overrun: something' reports from trace-cmd, where something
!= 0?
If you're not sure, please run the trace again. Also try adding '-r 10'
to the command line.
> I've run 4 commands in parallel. Also I can't get monitor information
> since vm is started using libvirt, so I've just used all machine's qemu-kvm
> pids..
Dan, is there a way to hijack the monitor so we can run some commands on
it? Things like 'info registers' and disassembly.
> hope it's OK
> here's the trace:
> http://nelide.cz/downloads/nik/trace.tar.bz2
> n.
>
Looks like vcpu 1 is spinning; perhaps that's normal. If you get hold
of the monitor, please disassemble around 0xfffff80001575d59.
vcpu 0 is busy writing to vga (can you confirm)? looks like bank
switching is hitting synchronize_srcu_expedited(), which is known slow.
Unfortunately that only gets better in 2.6.38.
You can try applying
http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commit;h=46fdb0937f26124700fc9fc80da4776330cc00d3
and see if it helps.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-06 10:19 ` Avi Kivity
@ 2011-01-06 10:25 ` Nikola Ciprich
2011-01-06 10:50 ` Avi Kivity
2011-01-06 11:06 ` Daniel P. Berrange
2011-01-06 12:18 ` Nikola Ciprich
2 siblings, 1 reply; 29+ messages in thread
From: Nikola Ciprich @ 2011-01-06 10:25 UTC (permalink / raw)
To: Avi Kivity; +Cc: KVM list, nikola.ciprich, Daniel P. Berrange
> Did you get 'overrun: something' reports from trace-cmd, where something
> != 0?
nope, all entries were 0.
> Dan, is there a way to hijack the monitor so we can run some commands on
> it? Things like 'info registers' and disassembly.
AFAIK that's intentionally not possible :(
pity..
> Looks like vcpu 1 is spinning; perhaps that's normal. If you get hold
> of the monitor, please disassemble around 0xfffff80001575d59.
>
> vcpu 0 is busy writing to vga (can you confirm)? looks like bank
> switching is hitting synchronize_srcu_expedited(), which is known slow.
> Unfortunately that only gets better in 2.6.38.
I guess it might help if I would just risk killing the machine and run
it without libvirt so we can debug better right?
or even better, I'll try to reproduce on another 2K8 windows on testing
machine and then we can play more with it.
gimme a few minutes please..
>
> You can try applying
> http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commit;h=46fdb0937f26124700fc9fc80da4776330cc00d3
> and see if it helps.
I'll also prepare testing kernel including this patch..
BTW Is it just me, or is git.kernel.org pretty slow today?
>
> --
> error compiling committee.c: too many arguments to function
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-06 10:25 ` Nikola Ciprich
@ 2011-01-06 10:50 ` Avi Kivity
0 siblings, 0 replies; 29+ messages in thread
From: Avi Kivity @ 2011-01-06 10:50 UTC (permalink / raw)
To: Nikola Ciprich; +Cc: KVM list, nikola.ciprich, Daniel P. Berrange
On 01/06/2011 12:25 PM, Nikola Ciprich wrote:
> > Did you get 'overrun: something' reports from trace-cmd, where something
> > != 0?
> nope, all entries were 0.
>
> > Dan, is there a way to hijack the monitor so we can run some commands on
> > it? Things like 'info registers' and disassembly.
> AFAIK that's intentionally not possible :(
> pity..
>
> > Looks like vcpu 1 is spinning; perhaps that's normal. If you get hold
> > of the monitor, please disassemble around 0xfffff80001575d59.
> >
> > vcpu 0 is busy writing to vga (can you confirm)? looks like bank
> > switching is hitting synchronize_srcu_expedited(), which is known slow.
> > Unfortunately that only gets better in 2.6.38.
> I guess it might help if I would just risk killing the machine and run
> it without libvirt so we can debug better right?
> or even better, I'll try to reproduce on another 2K8 windows on testing
> machine and then we can play more with it.
> gimme a few minutes please..
Thanks, a test machine that we can do horrible things to would be best.
> >
> > You can try applying
> > http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commit;h=46fdb0937f26124700fc9fc80da4776330cc00d3
> > and see if it helps.
> I'll also prepare testing kernel including this patch..
> BTW Is it just me, or is git.kernel.org pretty slow today?
2.6.37 is out, perhaps people are all over it.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-06 10:19 ` Avi Kivity
2011-01-06 10:25 ` Nikola Ciprich
@ 2011-01-06 11:06 ` Daniel P. Berrange
2011-01-06 12:19 ` Nikola Ciprich
2011-01-06 12:18 ` Nikola Ciprich
2 siblings, 1 reply; 29+ messages in thread
From: Daniel P. Berrange @ 2011-01-06 11:06 UTC (permalink / raw)
To: Avi Kivity; +Cc: Nikola Ciprich, KVM list, nikola.ciprich
On Thu, Jan 06, 2011 at 12:19:21PM +0200, Avi Kivity wrote:
> On 01/06/2011 11:42 AM, Nikola Ciprich wrote:
> >> - run trace-cmd record -e kvm -b 100000 -P pid1 -P pid2, ctrl-C after a
> >seems like it's not possible to specify multiple pids, so
>
> Did you get 'overrun: something' reports from trace-cmd, where
> something != 0?
>
> If you're not sure, please run the trace again. Also try adding '-r
> 10' to the command line.
>
> >I've run 4 commands in parallel. Also I can't get monitor information
> >since vm is started using libvirt, so I've just used all machine's qemu-kvm
> >pids..
>
> Dan, is there a way to hijack the monitor so we can run some
> commands on it? Things like 'info registers' and disassembly.
Depends on the libvirt version. For most, you'll need to
look for the monitor path in the QEMU argv:
-chardev
+socket,id=monitor,path=/var/lib/libvirt/qemu/vmwts02.monitor,server,nowait -mon chardev=monitor,mode=readline
then, 'service libvirtd stop' and now you can connect to
the monitor at that path & run commands you want, and then
disconnect and start libvirtd again. If you run any commands
that change the VM state, things may well get confused when
you start libvirtd again, but if its just 'info registers'
etc it should be pretty safe.
If you have a new enough libvirt, then you can also send
commands directly using 'virsh qemu-monitor-command' (checking
whether you need JSON or HMP syntax first - in this case you
can see it needs HMP).
Regards,
Daniel
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-06 10:19 ` Avi Kivity
2011-01-06 10:25 ` Nikola Ciprich
2011-01-06 11:06 ` Daniel P. Berrange
@ 2011-01-06 12:18 ` Nikola Ciprich
2011-01-06 13:26 ` Avi Kivity
2 siblings, 1 reply; 29+ messages in thread
From: Nikola Ciprich @ 2011-01-06 12:18 UTC (permalink / raw)
To: Avi Kivity; +Cc: KVM list, nikola.ciprich, Daniel P. Berrange
OK, got test environment running, but it seems to be running much faster
there :(
but as dan suggested, I can type monitor commands using virsh, so I can
(carefully:)) continue debugging on this production machine..
here's info registers:
RAX=0000000000000007 RBX=00000000000000ac RCX=fffff880009d1015 RDX=00000000000003ce
RSI=000000000000018a RDI=fffff8000163f737 RBP=0000000000000007 RSP=fffff88002588b08
R8 =000000000000000f R9 =00000000000000ac R10=0000000000007b20 R11=0000000000000008
R12=00000000000000a8 R13=0000000000000000 R14=000000000012c690 R15=00000000001d52d0
RIP=fffff8000156ae48 RFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =002b 0000000000000000 ffffffff 00c0f300 DPL=3 DS [-WA]
CS =0010 0000000000000000 00000000 00209b00 DPL=0 CS64 [-RA]
SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA]
DS =002b 0000000000000000 ffffffff 00c0f300 DPL=3 DS [-WA]
FS =0053 00000000fffe0000 00003c00 0040f300 DPL=3 DS [-WA]
GS =002b fffff80001644d00 ffffffff 00c0f300 DPL=3 DS [-WA]
LDT=0000 0000000000000000 ffffffff 00000000
TR =0040 fffff80002767080 00000067 00008b00 DPL=0 TSS64-busy
GDT= fffff80002766000 0000007f
IDT= fffff80002766080 00000fff
CR0=80050031 CR2=000000000047029a CR3=0000000094925000 CR4=000006f8
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000d01
FCW=027f FSW=0000 [ST=0] FTW=00 MXCSR=00001f80
FPR0=0000000000000000 0000 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=0000000000288c300000000000a000a0 XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000
XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000
XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000
XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000
> Looks like vcpu 1 is spinning; perhaps that's normal. If you get hold
> of the monitor, please disassemble around 0xfffff80001575d59.
ouch, can You advice me on how do I do it? :-[
>
> vcpu 0 is busy writing to vga (can you confirm)? looks like bank
yes, seems like screen refreshing is quite slow, certainly in this rescue mode
or what it is, it's not using any acceleration...
> switching is hitting synchronize_srcu_expedited(), which is known slow.
> Unfortunately that only gets better in 2.6.38.
>
> You can try applying
> http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commit;h=46fdb0937f26124700fc9fc80da4776330cc00d3
I'll be able to test this only on testing machine, or on this production maybe overnight..
I'll prepare the kernel anyways..
> and see if it helps.
>
> --
> error compiling committee.c: too many arguments to function
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-06 11:06 ` Daniel P. Berrange
@ 2011-01-06 12:19 ` Nikola Ciprich
0 siblings, 0 replies; 29+ messages in thread
From: Nikola Ciprich @ 2011-01-06 12:19 UTC (permalink / raw)
To: Daniel P. Berrange; +Cc: Avi Kivity, KVM list, nikola.ciprich
> If you have a new enough libvirt, then you can also send
> commands directly using 'virsh qemu-monitor-command' (checking
> whether you need JSON or HMP syntax first - in this case you
> can see it needs HMP).
Thanks Dan!
didn't know this is possible, works pretty well!
n.
>
> Regards,
> Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-06 12:18 ` Nikola Ciprich
@ 2011-01-06 13:26 ` Avi Kivity
2011-01-06 13:55 ` Nikola Ciprich
0 siblings, 1 reply; 29+ messages in thread
From: Avi Kivity @ 2011-01-06 13:26 UTC (permalink / raw)
To: Nikola Ciprich; +Cc: KVM list, nikola.ciprich, Daniel P. Berrange
On 01/06/2011 02:18 PM, Nikola Ciprich wrote:
> OK, got test environment running, but it seems to be running much faster
> there :(
Same host kernel?
> but as dan suggested, I can type monitor commands using virsh, so I can
> (carefully:)) continue debugging on this production machine..
> here's info registers:
> RAX=0000000000000007 RBX=00000000000000ac RCX=fffff880009d1015 RDX=00000000000003ce
> RSI=000000000000018a RDI=fffff8000163f737 RBP=0000000000000007 RSP=fffff88002588b08
> R8 =000000000000000f R9 =00000000000000ac R10=0000000000007b20 R11=0000000000000008
> R12=00000000000000a8 R13=0000000000000000 R14=000000000012c690 R15=00000000001d52d0
> RIP=fffff8000156ae48 RFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
>
That's cpu 0, which is busy writing stuff to the screen, not very
interesting.
> > Looks like vcpu 1 is spinning; perhaps that's normal. If you get hold
> > of the monitor, please disassemble around 0xfffff80001575d59.
> ouch, can You advice me on how do I do it? :-[
(qemu) cpu 1
(qemu) info registers
(qemu) x/100i 0xfffff80001575d59 - 35
> >
> > vcpu 0 is busy writing to vga (can you confirm)? looks like bank
> yes, seems like screen refreshing is quite slow, certainly in this rescue mode
> or what it is, it's not using any acceleration...
It's actually decelerated by synchronized_srcu_expedited(). It's one
area which got a large slowdown as the price for the great scalability
we achieved with srcu.
But wait, this doesn't make sense. If we see mmio to vga, then bank
switching is not involved, yet I see huge latencies on writes to vga io
ports.
Please install the qemu debuginfo package (if you built it yourself, I
hope it was with debug symbols enabled) and run 'perf top'.
> > switching is hitting synchronize_srcu_expedited(), which is known slow.
> > Unfortunately that only gets better in 2.6.38.
> >
> > You can try applying
> > http://git.kernel.org/?p=linux/kernel/git/sfr/linux-next.git;a=commit;h=46fdb0937f26124700fc9fc80da4776330cc00d3
> I'll be able to test this only on testing machine, or on this production maybe overnight..
> I'll prepare the kernel anyways..
>
I'm no longer sure this is the problem.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-06 13:26 ` Avi Kivity
@ 2011-01-06 13:55 ` Nikola Ciprich
2011-01-06 14:37 ` Avi Kivity
0 siblings, 1 reply; 29+ messages in thread
From: Nikola Ciprich @ 2011-01-06 13:55 UTC (permalink / raw)
To: Avi Kivity; +Cc: KVM list, nikola.ciprich, Daniel P. Berrange
> Same host kernel?
yes, I also disabled KSM now, se below.
>
> (qemu) cpu 1
> (qemu) info registers
RAX=0000000000000000 RBX=0000000000000000 RCX=0000000000000002 RDX=000055a900000000
RSI=fffffa8003660450 RDI=0000000000000001 RBP=0000000000000080 RSP=fffff880009f7cc0
R8 =0000000000000000 R9 =0000000000000f44 R10=fffff8000145a000 R11=0000000000000000
R12=0000000000000000 R13=fffff800015cada0 R14=0000000000000000 R15=fffff880009bcec0
RIP=fffff80001575d5b RFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
ES =002b 0000000000000000 ffffffff 00c0f300 DPL=3 DS [-WA]
CS =0010 0000000000000000 00000000 00209b00 DPL=0 CS64 [-RA]
SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA]
DS =002b 0000000000000000 ffffffff 00c0f300 DPL=3 DS [-WA]
FS =0053 00000000fffe0000 00007c00 0040f300 DPL=3 DS [-WA]
GS =002b fffff880009b8000 ffffffff 00c0f300 DPL=3 DS [-WA]
LDT=0000 0000000000000000 ffffffff 00000000
TR =0040 fffff880009bcec0 00000067 00008b00 DPL=0 TSS64-busy
GDT= fffff880009c34c0 0000007f
IDT= fffff880009c3540 00000fff
CR0=80050031 CR2=fffff8800121ca30 CR3=0000000000187000 CR4=000006f8
DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
DR6=00000000ffff0ff0 DR7=0000000000000400
EFER=0000000000000d01
FCW=027f FSW=3800 [ST=7] FTW=80 MXCSR=00001f80
FPR0=9fc0000000000000 4008 FPR1=0000000000000000 0000
FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
XMM00=99b6438668a3a8ed8cfd2d2540e9389a XMM01=00000000000000000000000000000000
XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000
XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000
XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000
XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000
> (qemu) x/100i 0xfffff80001575d59 - 35
virsh # qemu-monitor-command 2 "x/100i 0xfffff80001575d59 - 35"
0xfffff80001575d36: mov %ebp,0x18(%rsp)
0xfffff80001575d3a: push %rsi
0xfffff80001575d3b: push %rdi
0xfffff80001575d3c: push %r12
0xfffff80001575d3e: sub $0x30,%rsp
0xfffff80001575d42: mov %cr8,%rbx
0xfffff80001575d46: mov $0x2,%ecx
0xfffff80001575d4b: cmp %cl,%bl
0xfffff80001575d4d: ja 0xfffff80001575d67
0xfffff80001575d4f: cmpq $0x0,0x1598d1(%rip) # 0xfffff800016cf628
0xfffff80001575d57: je 0xfffff80001575d5d
0xfffff80001575d59: pause
0xfffff80001575d5b: jmp 0xfffff80001575d4f
0xfffff80001575d5d: mov %cr8,%rax
0xfffff80001575d61: mov %rcx,%cr8
0xfffff80001575d65: mov %al,%bl
0xfffff80001575d67: mov %gs:0x20,%rdi
0xfffff80001575d70: xor %r9d,%r9d
0xfffff80001575d73: btl $0x10,0xe38c9(%rip) # 0xfffff80001659644
0xfffff80001575d7b: jae 0xfffff80001575d95
0xfffff80001575d7d: mov $0x1,%sil
0xfffff80001575d80: rdtsc
0xfffff80001575d82: mov 0x4700(%rdi),%r12d
0xfffff80001575d89: shl $0x20,%rdx
0xfffff80001575d8d: or %rdx,%rax
0xfffff80001575d90: mov %rax,%rbp
0xfffff80001575d93: jmp 0xfffff80001575da2
0xfffff80001575d95: mov 0x50(%rsp),%rbp
0xfffff80001575d9a: mov 0x50(%rsp),%r12d
0xfffff80001575d9f: xor %sil,%sil
0xfffff80001575da2: incl 0x4b00(%rdi)
0xfffff80001575da8: lock btsq $0x0,0x159876(%rip) # 0xfffff800016cf628
0xfffff80001575db2: jae 0xfffff80001575dd1
0xfffff80001575db4: lea 0x15986d(%rip),%rcx # 0xfffff800016cf628
0xfffff80001575dbb: callq 0xfffff8000148c1c0
0xfffff80001575dc0: incl 0x4b04(%rdi)
0xfffff80001575dc6: add %eax,0x4b08(%rdi)
0xfffff80001575dcc: mov %eax,%r9d
0xfffff80001575dcf: jmp 0xfffff80001575dd4
0xfffff80001575dd1: lfence
0xfffff80001575dd4: test %sil,%sil
0xfffff80001575dd7: je 0xfffff80001575e01
0xfffff80001575dd9: rdtsc
0xfffff80001575ddb: shl $0x20,%rdx
0xfffff80001575ddf: lea 0x159842(%rip),%rcx # 0xfffff800016cf628
0xfffff80001575de6: movb $0x0,0x28(%rsp)
0xfffff80001575deb: or %rdx,%rax
0xfffff80001575dee: mov %r12d,0x20(%rsp)
0xfffff80001575df3: mov %eax,%r8d
0xfffff80001575df6: mov %rax,%rdx
0xfffff80001575df9: sub %ebp,%r8d
0xfffff80001575dfc: callq 0xfffff80001560f10
0xfffff80001575e01: mov 0x60(%rsp),%rbp
0xfffff80001575e06: mov %bl,0x159818(%rip) # 0xfffff800016cf624
0xfffff80001575e0c: mov 0x58(%rsp),%rbx
0xfffff80001575e11: add $0x30,%rsp
0xfffff80001575e15: pop %r12
0xfffff80001575e17: pop %rdi
0xfffff80001575e18: pop %rsi
0xfffff80001575e19: retq
0xfffff80001575e1a: nop
0xfffff80001575e1b: nop
0xfffff80001575e1c: nop
0xfffff80001575e1d: nop
0xfffff80001575e1e: nop
0xfffff80001575e1f: nop
0xfffff80001575e20: sub $0x58,%rsp
0xfffff80001575e24: mov %r8b,0x40(%rsp)
0xfffff80001575e29: xor %eax,%eax
0xfffff80001575e2b: movb $0x1,0x38(%rsp)
0xfffff80001575e30: cmp %al,0x10(%rdx)
0xfffff80001575e33: mov %rax,0x30(%rsp)
0xfffff80001575e38: mov 0x14(%rdx),%eax
0xfffff80001575e3b: mov %eax,0x28(%rsp)
0xfffff80001575e3f: mov 0x20(%rdx),%rax
0xfffff80001575e43: lea 0x8(%rdx),%r9
0xfffff80001575e47: mov %rdx,%r8
0xfffff80001575e4a: mov 0x18(%rdx),%rdx
0xfffff80001575e4e: mov %rax,0x20(%rsp)
0xfffff80001575e53: je 0xfffff80001575e5c
0xfffff80001575e55: callq 0xfffff8000147b73c
0xfffff80001575e5a: jmp 0xfffff80001575e61
0xfffff80001575e5c: callq 0xfffff8000147b144
0xfffff80001575e61: add $0x58,%rsp
0xfffff80001575e65: retq
0xfffff80001575e66: nop
0xfffff80001575e67: nop
0xfffff80001575e68: nop
0xfffff80001575e69: nop
0xfffff80001575e6a: nop
0xfffff80001575e6b: nop
0xfffff80001575e6c: nop
0xfffff80001575e6d: nop
0xfffff80001575e6e: nop
0xfffff80001575e6f: nop
0xfffff80001575e70: mov %rbx,0x10(%rsp)
0xfffff80001575e75: mov %rbp,0x18(%rsp)
0xfffff80001575e7a: mov %rsi,0x20(%rsp)
0xfffff80001575e7f: push %rdi
0xfffff80001575e80: push %r12
> It's actually decelerated by synchronized_srcu_expedited(). It's one
> area which got a large slowdown as the price for the great scalability
> we achieved with srcu.
>
> But wait, this doesn't make sense. If we see mmio to vga, then bank
> switching is not involved, yet I see huge latencies on writes to vga io
> ports.
>
> Please install the qemu debuginfo package (if you built it yourself, I
> hope it was with debug symbols enabled) and run 'perf top'.
sure, here it is. it showed a lot of KSM activity:
2276.00 12.1% memcmp_pages [kernel.kallsyms]
1613.00 8.6% ksm_scan_thread [kernel.kallsyms]
hence I disabled KSM.
here's perf top then, checkdisk is still slow:
412.00 8.6% do_raw_spin_lock [kernel.kallsyms]
235.00 4.9% send_mono_rect /usr/bin/qemu-kvm
215.00 4.5% rb_next [kernel.kallsyms]
166.00 3.5% schedule [kernel.kallsyms]
141.00 3.0% add_preempt_count [kernel.kallsyms]
137.00 2.9% gen_rotc_rm_T1 /usr/bin/qemu-kvm
127.00 2.7% vmx_vcpu_run /lib/modules/2.6.36lb.03/kernel/arch/x86/kvm/kvm-intel.ko
120.00 2.5% kvm_mmu_prepare_zap_page /lib/modules/2.6.36lb.03/kernel/arch/x86/kvm/kvm.ko
103.00 2.2% sub_preempt_count [kernel.kallsyms]
102.00 2.1% debug_smp_processor_id [kernel.kallsyms]
87.00 1.8% delay_tsc [kernel.kallsyms]
62.00 1.3% cpupri_set [kernel.kallsyms]
60.00 1.3% vmcs_readl /lib/modules/2.6.36lb.03/kernel/arch/x86/kvm/kvm-intel.ko
59.00 1.2% cpu_stopper_thread [kernel.kallsyms]
57.00 1.2% select_nohz_load_balancer [kernel.kallsyms]
56.00 1.2% memset /lib64/libc-2.5.so
52.00 1.1% alloc_vmap_area [kernel.kallsyms]
50.00 1.0% copy_user_generic_string [kernel.kallsyms]
46.00 1.0% gfn_to_memslot /lib/modules/2.6.36lb.03/kernel/arch/x86/kvm/kvm.ko
38.00 0.8% is_shadow_present_pte /lib/modules/2.6.36lb.03/kernel/arch/x86/kvm/kvm.ko
38.00 0.8% read_tsc [kernel.kallsyms]
35.00 0.7% sched_clock_local [kernel.kallsyms]
35.00 0.7% sched_clock [kernel.kallsyms]
35.00 0.7% cirrus_fill_src_or_dst_32 /usr/bin/qemu-kvm
33.00 0.7% cpu_stop_signal_done [kernel.kallsyms]
33.00 0.7% gen_rot_rm_T1 /usr/bin/qemu-kvm
31.00 0.7% do_raw_spin_unlock [kernel.kallsyms]
30.00 0.6% __enqueue_rt_entity [kernel.kallsyms]
30.00 0.6% gen_shift_rm_T1 /usr/bin/qemu-kvm
29.00 0.6% load_balance [kernel.kallsyms]
29.00 0.6% sched_clock_cpu [kernel.kallsyms]
29.00 0.6% _raw_spin_unlock_irqrestore [kernel.kallsyms]
28.00 0.6% __might_sleep [kernel.kallsyms]
28.00 0.6% finish_task_switch [kernel.kallsyms]
28.00 0.6% pick_next_task_rt [kernel.kallsyms]
28.00 0.6% tick_nohz_restart_sched_tick [kernel.kallsyms]
.
.
.
>
> I'm no longer sure this is the problem.
>
> --
> error compiling committee.c: too many arguments to function
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-06 13:55 ` Nikola Ciprich
@ 2011-01-06 14:37 ` Avi Kivity
2011-01-06 15:38 ` Nikola Ciprich
0 siblings, 1 reply; 29+ messages in thread
From: Avi Kivity @ 2011-01-06 14:37 UTC (permalink / raw)
To: Nikola Ciprich; +Cc: KVM list, nikola.ciprich, Daniel P. Berrange
On 01/06/2011 03:55 PM, Nikola Ciprich wrote:
> > Same host kernel?
> yes, I also disabled KSM now, se below.
> >
> > (qemu) cpu 1
> > (qemu) info registers
>
> RAX=0000000000000000 RBX=0000000000000000 RCX=0000000000000002 RDX=000055a900000000
> RSI=fffffa8003660450 RDI=0000000000000001 RBP=0000000000000080 RSP=fffff880009f7cc0
> R8 =0000000000000000 R9 =0000000000000f44 R10=fffff8000145a000 R11=0000000000000000
> R12=0000000000000000 R13=fffff800015cada0 R14=0000000000000000 R15=fffff880009bcec0
> RIP=fffff80001575d5b RFL=00000202 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =002b 0000000000000000 ffffffff 00c0f300 DPL=3 DS [-WA]
> CS =0010 0000000000000000 00000000 00209b00 DPL=0 CS64 [-RA]
> SS =0018 0000000000000000 ffffffff 00c09300 DPL=0 DS [-WA]
> DS =002b 0000000000000000 ffffffff 00c0f300 DPL=3 DS [-WA]
> FS =0053 00000000fffe0000 00007c00 0040f300 DPL=3 DS [-WA]
> GS =002b fffff880009b8000 ffffffff 00c0f300 DPL=3 DS [-WA]
> LDT=0000 0000000000000000 ffffffff 00000000
> TR =0040 fffff880009bcec0 00000067 00008b00 DPL=0 TSS64-busy
> GDT= fffff880009c34c0 0000007f
> IDT= fffff880009c3540 00000fff
> CR0=80050031 CR2=fffff8800121ca30 CR3=0000000000187000 CR4=000006f8
> DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000 DR3=0000000000000000
> DR6=00000000ffff0ff0 DR7=0000000000000400
> EFER=0000000000000d01
> FCW=027f FSW=3800 [ST=7] FTW=80 MXCSR=00001f80
> FPR0=9fc0000000000000 4008 FPR1=0000000000000000 0000
> FPR2=0000000000000000 0000 FPR3=0000000000000000 0000
> FPR4=0000000000000000 0000 FPR5=0000000000000000 0000
> FPR6=0000000000000000 0000 FPR7=0000000000000000 0000
> XMM00=99b6438668a3a8ed8cfd2d2540e9389a XMM01=00000000000000000000000000000000
> XMM02=00000000000000000000000000000000 XMM03=00000000000000000000000000000000
> XMM04=00000000000000000000000000000000 XMM05=00000000000000000000000000000000
> XMM06=00000000000000000000000000000000 XMM07=00000000000000000000000000000000
> XMM08=00000000000000000000000000000000 XMM09=00000000000000000000000000000000
> XMM10=00000000000000000000000000000000 XMM11=00000000000000000000000000000000
> XMM12=00000000000000000000000000000000 XMM13=00000000000000000000000000000000
> XMM14=00000000000000000000000000000000 XMM15=00000000000000000000000000000000
>
>
>
> > (qemu) x/100i 0xfffff80001575d59 - 35
> virsh # qemu-monitor-command 2 "x/100i 0xfffff80001575d59 - 35"
> 0xfffff80001575d36: mov %ebp,0x18(%rsp)
> 0xfffff80001575d3a: push %rsi
> 0xfffff80001575d3b: push %rdi
> 0xfffff80001575d3c: push %r12
> 0xfffff80001575d3e: sub $0x30,%rsp
> 0xfffff80001575d42: mov %cr8,%rbx
> 0xfffff80001575d46: mov $0x2,%ecx
> 0xfffff80001575d4b: cmp %cl,%bl
> 0xfffff80001575d4d: ja 0xfffff80001575d67
> 0xfffff80001575d4f: cmpq $0x0,0x1598d1(%rip) # 0xfffff800016cf628
> 0xfffff80001575d57: je 0xfffff80001575d5d
> 0xfffff80001575d59: pause
rip points here, reasonable for a spin loop, but what it's spinning on,
I can't imagine.
Maybe some bug in kvm caused Windows to spin here endlessly and that's
what's causing the problem, this is consistent with you not reproducing
it on the test machine.
> hence I disabled KSM.
> here's perf top then, checkdisk is still slow:
> 412.00 8.6% do_raw_spin_lock [kernel.kallsyms]
$ perf record -a -f -g
$ perf report -g
will show who calls do_raw_spin_lock.
> 235.00 4.9% send_mono_rect /usr/bin/qemu-kvm
> 215.00 4.5% rb_next [kernel.kallsyms]
> 166.00 3.5% schedule [kernel.kallsyms]
What's the context switch rate? 'vmstat 1'
> 141.00 3.0% add_preempt_count [kernel.kallsyms]
> 137.00 2.9% gen_rotc_rm_T1 /usr/bin/qemu-kvm
Do you have a guest running with kvm disabled?!
> 127.00 2.7% vmx_vcpu_run /lib/modules/2.6.36lb.03/kernel/arch/x86/kvm/kvm-intel.ko
That's guest time. Puny.
> 120.00 2.5% kvm_mmu_prepare_zap_page /lib/modules/2.6.36lb.03/kernel/arch/x86/kvm/kvm.ko
Could be a couple of things.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-06 14:37 ` Avi Kivity
@ 2011-01-06 15:38 ` Nikola Ciprich
2011-01-09 12:36 ` Nikola Ciprich
0 siblings, 1 reply; 29+ messages in thread
From: Nikola Ciprich @ 2011-01-06 15:38 UTC (permalink / raw)
To: Avi Kivity; +Cc: KVM list, nikola.ciprich, Daniel P. Berrange
>
> $ perf record -a -f -g
> $ perf report -g
here we go:
here we go:
- 49.72% _raw_spin_lock ▒
- 32.32% kvm_mmu_pte_write ▒
- 98.02% emulator_write_phys ▒
emulator_write_emulated_onepage ▒
emulator_write_emulated ▒
x86_emulate_insn ▒
emulate_instruction ▒
kvm_mmu_page_fault ▒
handle_exception ▒
vmx_handle_exit ▒
kvm_arch_vcpu_ioctl_run ▒
kvm_vcpu_ioctl ▒
vfs_ioctl ▒
do_vfs_ioctl ▒
sys_ioctl ▒
system_call_fastpath ▒
__GI_ioctl ▒
- 1.98% paging64_invlpg ▒
kvm_mmu_invlpg ▒
handle_invlpg ▒
vmx_handle_exit ▒
kvm_arch_vcpu_ioctl_run ▒
kvm_vcpu_ioctl ▒
vfs_ioctl ▒
do_vfs_ioctl ▒
sys_ioctl ▒
system_call_fastpath ▒
__GI_ioctl ▒
- 23.66% task_rq_lock ▒
- try_to_wake_up ▒
- 94.76% wake_up_process ▒
cpu_stop_queue_work ▒
__stop_cpus ▒
try_stop_cpus ▒
synchronize_sched_expedited ▒
__synchronize_srcu ▒
synchronize_srcu_expedited ▒
__kvm_set_memory_region ▒
kvm_set_memory_region ▒
kvm_vm_ioctl_set_memory_region ▒
kvm_vm_ioctl ▒
vfs_ioctl ▒
do_vfs_ioctl ▒
sys_ioctl ▒
system_call_fastpath ▒
__GI_ioctl ▒
- 4.44% default_wake_function ▒
- 53.81% autoremove_wake_function ▒
__wake_up_common ▒
__wake_up ▒
kvm_vcpu_kick ▒
__apic_accept_irq ▒
kvm_apic_set_irq ▒
- kvm_irq_delivery_to_apic ▒
- 58.41% apic_reg_write ▒
apic_mmio_write ▒
emulator_write_emulated_onepage ▒
emulator_write_emulated ▒
x86_emulate_insn ▒
emulate_instruction ▒
kvm_mmu_page_fault ▒
handle_exception ▒
vmx_handle_exit ▒
kvm_arch_vcpu_ioctl_run ▒
kvm_vcpu_ioctl ▒
vfs_ioctl ▒
do_vfs_ioctl ▒
sys_ioctl ▒
system_call_fastpath ▒
__GI_ioctl ▒
- 29.60% ioapic_service ▒
kvm_ioapic_set_irq ▒
kvm_set_ioapic_irq ▒
kvm_set_irq ▒
kvm_arch_vm_ioctl ▒
kvm_vm_ioctl ▒
vfs_ioctl ▒
do_vfs_ioctl ▒
sys_ioctl ▒
system_call_fastpath ▒
__GI_ioctl ▒
- 11.99% kvm_set_msi ▒
kvm_set_irq ▒
kvm_arch_vm_ioctl ▒
kvm_vm_ioctl ▒
vfs_ioctl ▒
do_vfs_ioctl ▒
sys_ioctl ▒
system_call_fastpath ▒
__GI_ioctl ▒
- 46.19% pollwake ▒
__wake_up_common ▒
- __wake_up ▒
- 77.30% __send_signal ▒
send_signal ▒
- do_send_sig_info ▒
- 68.83% do_send_specific ▒
do_tkill ▒
sys_tgkill ▒
system_call_fastpath ▒
__pthread_kill ▒
- 31.17% group_send_sig_info ▒
kill_pid_info ▒
sys_kill ▒
system_call_fastpath ▒
__kill ▒
- 22.70% send_sigqueue ▒
posix_timer_event ▒
posix_timer_fn ▒
__run_hrtimer ▒
hrtimer_interrupt ▒
smp_apic_timer_interrupt ▒
apic_timer_interrupt ▒
kvm_arch_commit_memory_region ▒
__kvm_set_memory_region ▒
kvm_set_memory_region ▒
kvm_vm_ioctl_set_memory_region ▒
kvm_vm_ioctl ▒
vfs_ioctl ▒
do_vfs_ioctl ▒
sys_ioctl ▒
system_call_fastpath ▒
__GI_ioctl ▒
- 0.80% wake_up_state ▒
- wake_futex ▒
- 68.01% do_futex ▒
sys_futex ▒
system_call_fastpath ▒
__pthread_cond_signal ▒
- 31.99% futex_wake ▒
do_futex ▒
sys_futex ▒
system_call_fastpath ▒
__lll_unlock_wake ▒
- 11.51% mmu_free_roots ▒
- 96.89% kvm_mmu_unload ▒
kvm_arch_vcpu_ioctl_run ▒
kvm_vcpu_ioctl ▒
vfs_ioctl ▒
do_vfs_ioctl ▒
sys_ioctl ▒
system_call_fastpath ▒
__GI_ioctl ▒
- 3.11% paging_new_cr3 ▒
kvm_set_cr3 ▒
handle_cr ▒
vmx_handle_exit ▒
kvm_arch_vcpu_ioctl_run ▒
kvm_vcpu_ioctl ▒
vfs_ioctl ▒
do_vfs_ioctl ▒
sys_ioctl ▒
system_call_fastpath ▒
__GI_ioctl ▒
- 6.78% paging64_page_fault ▒
kvm_mmu_page_fault ▒
handle_exception ▒
vmx_handle_exit ▒
kvm_arch_vcpu_ioctl_run ▒
kvm_vcpu_ioctl ▒
vfs_ioctl ▒
do_vfs_ioctl ▒
sys_ioctl ▒
system_call_fastpath ▒
__GI_ioctl ▒
- 5.72% make_all_cpus_request ▒
- 62.13% kvm_reload_remote_mmus ▒
- kvm_mmu_prepare_zap_page ▒
- 96.56% kvm_mmu_zap_all ▒
kvm_arch_flush_shadow ▒
__kvm_set_memory_region ▒
kvm_set_memory_region ▒
kvm_vm_ioctl_set_memory_region ▒
kvm_vm_ioctl ▒
vfs_ioctl ▒
do_vfs_ioctl ▒
sys_ioctl ▒
system_call_fastpath ▒
__GI_ioctl ▒
- 3.44% kvm_mmu_pte_write ▒
emulator_write_phys ▒
emulator_write_emulated_onepage ▒
emulator_write_emulated ▒
x86_emulate_insn ▒
emulate_instruction ▒
kvm_mmu_page_fault ▒
handle_exception ▒
vmx_handle_exit ▒
kvm_arch_vcpu_ioctl_run ▒
kvm_vcpu_ioctl ▒
vfs_ioctl ▒
do_vfs_ioctl ▒
sys_ioctl ▒
system_call_fastpath ▒
__GI_ioctl ▒
.
.
it's not all, is this enough? or can I simply export whole tree somehow?
>
> will show who calls do_raw_spin_lock.
>
>> 235.00 4.9% send_mono_rect /usr/bin/qemu-kvm
>> 215.00 4.5% rb_next [kernel.kallsyms]
>> 166.00 3.5% schedule [kernel.kallsyms]
>
> What's the context switch rate? 'vmstat 1'
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
3 0 0 168920 5841008 4614064 0 0 28 21 32 28 15 22 63 0 0
2 0 0 168820 5841008 4614088 0 0 0 0 13489 76739 15 16 69 0 0
2 0 0 167656 5841008 4614088 0 0 0 104 6089 33390 16 13 71 0 0
3 0 0 169184 5841008 4614088 0 0 0 0 12489 71263 17 15 69 0 0
2 0 0 169200 5841012 4614092 0 0 0 8 7034 33908 17 12 72 0 0
2 0 0 169432 5841024 4614080 0 0 0 16 10924 67008 16 12 72 0 0
2 0 0 168084 5841028 4614088 0 0 0 4 8955 47767 17 13 71 0 0
2 0 0 168936 5841032 4614088 0 0 0 80 9528 50119 16 13 71 0 0
.
.
>
>> 141.00 3.0% add_preempt_count [kernel.kallsyms]
>> 137.00 2.9% gen_rotc_rm_T1 /usr/bin/qemu-kvm
>
> Do you have a guest running with kvm disabled?!
nope, all seem to be using KVM
>
>
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-06 15:38 ` Nikola Ciprich
@ 2011-01-09 12:36 ` Nikola Ciprich
2011-01-09 12:39 ` Avi Kivity
0 siblings, 1 reply; 29+ messages in thread
From: Nikola Ciprich @ 2011-01-09 12:36 UTC (permalink / raw)
To: Avi Kivity; +Cc: KVM list, nikola.ciprich, Daniel P. Berrange
Avi,
I was forced to interrupt checkdisk on this machine, I tried it again
and it's reproducible (even on another (testing) W2K8 guests).
I transfered the image to testing machine where chkdsk runs OK and finished
it there.
So in case You'd like to continue debugging, I'm at Your disposal, we can create
more testing guests and play with them on host where I can reproduce.
So far thanks a lot for all the time You've spent with it.
BR
nik
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-09 12:36 ` Nikola Ciprich
@ 2011-01-09 12:39 ` Avi Kivity
2011-01-09 13:36 ` Nikola Ciprich
0 siblings, 1 reply; 29+ messages in thread
From: Avi Kivity @ 2011-01-09 12:39 UTC (permalink / raw)
To: Nikola Ciprich; +Cc: KVM list, nikola.ciprich, Daniel P. Berrange
On 01/09/2011 02:36 PM, Nikola Ciprich wrote:
> Avi,
> I was forced to interrupt checkdisk on this machine, I tried it again
> and it's reproducible (even on another (testing) W2K8 guests).
> I transfered the image to testing machine where chkdsk runs OK and finished
> it there.
> So in case You'd like to continue debugging, I'm at Your disposal, we can create
> more testing guests and play with them on host where I can reproduce.
> So far thanks a lot for all the time You've spent with it.
> BR
> nik
>
What are the differences between the host the completes chkdsk and the
host that fails? Hardware-wise and software-wise.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-09 12:39 ` Avi Kivity
@ 2011-01-09 13:36 ` Nikola Ciprich
2011-01-09 13:44 ` Nikola Ciprich
2011-01-09 14:13 ` Avi Kivity
0 siblings, 2 replies; 29+ messages in thread
From: Nikola Ciprich @ 2011-01-09 13:36 UTC (permalink / raw)
To: Avi Kivity; +Cc: KVM list, nikola.ciprich, Daniel P. Berrange
> What are the differences between the host the completes chkdsk and the
> host that fails? Hardware-wise and software-wise.
Software-wise, I'm not aware of any, both nodes use:
- kernel 2.6.36.2
- qemu-kvm-0.13.0
- seabios-0.6.0
hardware-wise, problematic machine is older 8core, 16GB RAM,
cpuinfo snippet:
processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 15
model name : Intel(R) Xeon(R) CPU E5310 @ 1.60GHz
stepping : 7
cpu MHz : 1599.873
cache size : 4096 KB
physical id : 1
siblings : 4
core id : 3
cpu cores : 4
apicid : 7
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx tm2 ssse3 cx16 xtpr pdcm dca lahf_lm dts tpr_shadow
bogomips : 3200.27
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
nonproblematic machine is 8core 4GB, cpuinfo snippet:
processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 30
model name : Intel(R) Xeon(R) CPU X3440 @ 2.53GHz
stepping : 5
cpu MHz : 2533.260
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 7
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good xtopology nonstop_tsc aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 popcnt lahf_lm ida dts tpr_shadow vnmi flexpriority ept vpid
bogomips : 5066.35
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
important to note is, that botch machines are failover clusters, I can reproduce even on second node
of "problematic" cluster, although CPU is a bit different, snippet follows:
processor : 7
vendor_id : GenuineIntel
cpu family : 6
model : 23
model name : Intel(R) Xeon(R) CPU E5420 @ 2.50GHz
stepping : 6
cpu MHz : 2500.038
cache size : 6144 KB
physical id : 1
siblings : 4
core id : 3
cpu cores : 4
apicid : 7
initial apicid : 7
fpu : yes
fpu_exception : yes
cpuid level : 10
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts rep_good aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm dca sse4_1 lahf_lm dts tpr_shadow vnmi flexpriority
bogomips : 5000.40
clflush size : 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
What else could I check?
n.
>
> --
> error compiling committee.c: too many arguments to function
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-09 13:36 ` Nikola Ciprich
@ 2011-01-09 13:44 ` Nikola Ciprich
2011-01-09 14:13 ` Avi Kivity
2011-01-09 14:13 ` Avi Kivity
1 sibling, 1 reply; 29+ messages in thread
From: Nikola Ciprich @ 2011-01-09 13:44 UTC (permalink / raw)
To: Avi Kivity; +Cc: KVM list, nikola.ciprich, Daniel P. Berrange
On Sun, Jan 09, 2011 at 02:36:55PM +0100, Nikola Ciprich wrote:
> > What are the differences between the host the completes chkdsk and the
> > host that fails? Hardware-wise and software-wise.
> Software-wise, I'm not aware of any, both nodes use:
> - kernel 2.6.36.2
> - qemu-kvm-0.13.0
> - seabios-0.6.0
huh, I noticed now, it's not clean 0.13.0, but 0.13.0 + patches up to 420fe74769cc67baec6f3d962dc054e2972ca3ae.
but it's the same on both machines, problematic and nonproblematic.
hope it's not problem, sorry for the mess :(
n.
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-09 13:36 ` Nikola Ciprich
2011-01-09 13:44 ` Nikola Ciprich
@ 2011-01-09 14:13 ` Avi Kivity
2011-01-09 14:27 ` Nikola Ciprich
1 sibling, 1 reply; 29+ messages in thread
From: Avi Kivity @ 2011-01-09 14:13 UTC (permalink / raw)
To: Nikola Ciprich; +Cc: KVM list, nikola.ciprich, Daniel P. Berrange
On 01/09/2011 03:36 PM, Nikola Ciprich wrote:
> > What are the differences between the host the completes chkdsk and the
> > host that fails? Hardware-wise and software-wise.
> Software-wise, I'm not aware of any, both nodes use:
> - kernel 2.6.36.2
> - qemu-kvm-0.13.0
> - seabios-0.6.0
>
> hardware-wise, problematic machine is older 8core, 16GB RAM,
> cpuinfo snippet:
>
> processor : 7
> vendor_id : GenuineIntel
> cpu family : 6
> model : 15
> model name : Intel(R) Xeon(R) CPU E5310 @ 1.60GHz
Please try the newer machine, after rmmoding kvm-intel, and reloading it
with the module parameter ept=0.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-09 13:44 ` Nikola Ciprich
@ 2011-01-09 14:13 ` Avi Kivity
0 siblings, 0 replies; 29+ messages in thread
From: Avi Kivity @ 2011-01-09 14:13 UTC (permalink / raw)
To: Nikola Ciprich; +Cc: KVM list, nikola.ciprich, Daniel P. Berrange
On 01/09/2011 03:44 PM, Nikola Ciprich wrote:
> On Sun, Jan 09, 2011 at 02:36:55PM +0100, Nikola Ciprich wrote:
> > > What are the differences between the host the completes chkdsk and the
> > > host that fails? Hardware-wise and software-wise.
> > Software-wise, I'm not aware of any, both nodes use:
> > - kernel 2.6.36.2
> > - qemu-kvm-0.13.0
> > - seabios-0.6.0
> huh, I noticed now, it's not clean 0.13.0, but 0.13.0 + patches up to 420fe74769cc67baec6f3d962dc054e2972ca3ae.
> but it's the same on both machines, problematic and nonproblematic.
> hope it's not problem, sorry for the mess :(
It's not a problem, and in any case unlikely to cause the bug.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-09 14:13 ` Avi Kivity
@ 2011-01-09 14:27 ` Nikola Ciprich
2011-01-09 14:36 ` Avi Kivity
0 siblings, 1 reply; 29+ messages in thread
From: Nikola Ciprich @ 2011-01-09 14:27 UTC (permalink / raw)
To: Avi Kivity; +Cc: KVM list, nikola.ciprich, Daniel P. Berrange
> Please try the newer machine, after rmmoding kvm-intel, and reloading it
> with the module parameter ept=0.
seems to be OK even with parameter..
n.
>
>
> --
> error compiling committee.c: too many arguments to function
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-09 14:27 ` Nikola Ciprich
@ 2011-01-09 14:36 ` Avi Kivity
2011-01-09 15:15 ` Nikola Ciprich
0 siblings, 1 reply; 29+ messages in thread
From: Avi Kivity @ 2011-01-09 14:36 UTC (permalink / raw)
To: Nikola Ciprich; +Cc: KVM list, nikola.ciprich, Daniel P. Berrange
On 01/09/2011 04:27 PM, Nikola Ciprich wrote:
> > Please try the newer machine, after rmmoding kvm-intel, and reloading it
> > with the module parameter ept=0.
> seems to be OK even with parameter..
> n.
Ok. Is chkdsk outside the preboot environment working okay on the bad host?
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-09 14:36 ` Avi Kivity
@ 2011-01-09 15:15 ` Nikola Ciprich
2011-01-09 20:10 ` Nikola Ciprich
0 siblings, 1 reply; 29+ messages in thread
From: Nikola Ciprich @ 2011-01-09 15:15 UTC (permalink / raw)
To: Avi Kivity; +Cc: KVM list, nikola.ciprich, Daniel P. Berrange
> Ok. Is chkdsk outside the preboot environment working okay on the bad host?
I'll check, give me some time, I'll have to add another large volume which I can
check while the system is up..
in the meantime, on hosts, I noticed following messages:
[322172.007569] kvm: 17743: cpu1 unhandled wrmsr: 0x198 data 0
it's on all (problematic and nonproblematic machines).
dunno if this could be somehow related..
n.
>
> --
> error compiling committee.c: too many arguments to function
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-09 15:15 ` Nikola Ciprich
@ 2011-01-09 20:10 ` Nikola Ciprich
2011-01-10 9:23 ` Avi Kivity
0 siblings, 1 reply; 29+ messages in thread
From: Nikola Ciprich @ 2011-01-09 20:10 UTC (permalink / raw)
To: Avi Kivity; +Cc: KVM list, nikola.ciprich, Daniel P. Berrange
Hi Avi,
sorry it took so long.
running chkdsk from windows is OK, runs pretty fast.
so there must be something different in this preboot environment.
n.
On Sun, Jan 09, 2011 at 04:15:19PM +0100, Nikola Ciprich wrote:
> > Ok. Is chkdsk outside the preboot environment working okay on the bad host?
> I'll check, give me some time, I'll have to add another large volume which I can
> check while the system is up..
>
> in the meantime, on hosts, I noticed following messages:
> [322172.007569] kvm: 17743: cpu1 unhandled wrmsr: 0x198 data 0
> it's on all (problematic and nonproblematic machines).
> dunno if this could be somehow related..
> n.
>
> >
> > --
> > error compiling committee.c: too many arguments to function
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe kvm" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
> --
> -------------------------------------
> Ing. Nikola CIPRICH
> LinuxBox.cz, s.r.o.
> 28. rijna 168, 709 01 Ostrava
>
> tel.: +420 596 603 142
> fax: +420 596 621 273
> mobil: +420 777 093 799
>
> www.linuxbox.cz
>
> mobil servis: +420 737 238 656
> email servis: servis@linuxbox.cz
> -------------------------------------
> --
> To unsubscribe from this list: send the line "unsubscribe kvm" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
-------------------------------------
Ing. Nikola CIPRICH
LinuxBox.cz, s.r.o.
28. rijna 168, 709 01 Ostrava
tel.: +420 596 603 142
fax: +420 596 621 273
mobil: +420 777 093 799
www.linuxbox.cz
mobil servis: +420 737 238 656
email servis: servis@linuxbox.cz
-------------------------------------
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow
2011-01-09 20:10 ` Nikola Ciprich
@ 2011-01-10 9:23 ` Avi Kivity
0 siblings, 0 replies; 29+ messages in thread
From: Avi Kivity @ 2011-01-10 9:23 UTC (permalink / raw)
To: Nikola Ciprich; +Cc: KVM list, nikola.ciprich, Daniel P. Berrange
On 01/09/2011 10:10 PM, Nikola Ciprich wrote:
> Hi Avi,
> sorry it took so long.
> running chkdsk from windows is OK, runs pretty fast.
> so there must be something different in this preboot environment.
Let's try to see what's the difference between the working machine and
the bad one.
Please compare several kvm_stat snapshots, see if something stands out.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2011-01-10 9:23 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-06 7:48 qemu-kvm-0.13.0 - winsows 2008 - chkdisk too slow Nikola Ciprich
2011-01-06 9:03 ` Stefan Hajnoczi
2011-01-06 9:06 ` Nikola Ciprich
2011-01-06 9:08 ` Avi Kivity
2011-01-06 9:20 ` Nikola Ciprich
2011-01-06 9:27 ` Avi Kivity
2011-01-06 9:30 ` Avi Kivity
2011-01-06 9:42 ` Nikola Ciprich
2011-01-06 10:19 ` Avi Kivity
2011-01-06 10:25 ` Nikola Ciprich
2011-01-06 10:50 ` Avi Kivity
2011-01-06 11:06 ` Daniel P. Berrange
2011-01-06 12:19 ` Nikola Ciprich
2011-01-06 12:18 ` Nikola Ciprich
2011-01-06 13:26 ` Avi Kivity
2011-01-06 13:55 ` Nikola Ciprich
2011-01-06 14:37 ` Avi Kivity
2011-01-06 15:38 ` Nikola Ciprich
2011-01-09 12:36 ` Nikola Ciprich
2011-01-09 12:39 ` Avi Kivity
2011-01-09 13:36 ` Nikola Ciprich
2011-01-09 13:44 ` Nikola Ciprich
2011-01-09 14:13 ` Avi Kivity
2011-01-09 14:13 ` Avi Kivity
2011-01-09 14:27 ` Nikola Ciprich
2011-01-09 14:36 ` Avi Kivity
2011-01-09 15:15 ` Nikola Ciprich
2011-01-09 20:10 ` Nikola Ciprich
2011-01-10 9:23 ` Avi Kivity
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox