Hi, I captured the output of pidstat when the problem was reproduced:
bash-4.1# pidstat -p $PID 8966 Linux 2.6.32-71.el6.x86_64 (test) 07/24/11 _x86_64_ (4 CPU) 16:25:15 PID %usr %system %guest %CPU CPU Command 16:25:15 8966 0.14 55.04 115.41 170.59 1 qemu-kvm Thanks, Paul On Tue, Aug 23, 2011 at 6:09 PM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > > On Tue, Aug 23, 2011 at 9:10 AM, Paul <fly...@gmail.com> wrote: > > From trace messages, it seemed no interrupts for guest. > > I also tried sysrq, but it didn't work. I doubt that kvm-qemu entered > > some infinite loop. > > The fact that a fresh VNC connection to the guest works (but the mouse > doesn't move) means that qemu-kvm itself is not completely locked up. > The VNC server runs in a qemu-kvm thread. > > So this seems to be a problem inside the guest that causes it to > consume 100% CPU. > > One way to confirm this is to run pidstat(1): > $ pidstat -p $PID 1 > 11:05:51 PID %usr %system %guest %CPU CPU Command > 11:06:05 26994 65.00 0.00 98.00 163.00 1 kvm > > The %guest value is the percentage spent executing guest code. The > %usr time is the percentage spent executing qemu-kvm userspace code. > I'm guessing you will see >80% %guest. > > In my example I was running while true; do true; done inside the guest :). > > Perhaps Avi can suggest kvm_stat or other techniques to discover what > exactly this guest is doing. > > Stefan -- 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
