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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
