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

Reply via email to