From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [Bug #12465] KVM guests stalling on 2.6.28 (bisected) Date: Sun, 15 Mar 2009 11:03:29 +0100 Message-ID: <20090315100329.GA23577@elte.hu> References: <9nR7rAsBwYG.A.iEG.fOCvJB@chimera> <1237107837.27699.27.camel@kulgan.wumi.org.au> <49BCC7C8.2020503@redhat.com> <20090315094807.GB21169@elte.hu> <49BCD0E9.9000305@redhat.com> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: <49BCD0E9.9000305@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Avi Kivity Cc: Peter Zijlstra , Mike Galbraith , Kevin Shanahan , "Rafael J. Wysocki" , Linux Kernel Mailing List , Kernel Testers List * Avi Kivity wrote: > Ingo Molnar wrote: >>> I've looked at the traces but lack the skill to make any sense out of >>> them. >>> >> >> Do you have specific questions about them that we could answer? >> > > A general question: what's going on? I guess this will only > be answered by me getting my hands dirty and understanding how > ftrace works and how the output maps to what's happening. > I'll look at the docs for a while. > > A specific question for now is how can I identify long latency > within qemu here? As far as I can tell all qemu latencies in > trace6.txt are sub 100ms, which, while long, don't explain the > guest stalling for many seconds. Exactly - that in turn means that there's no scheduler latency on the host/native kernel side - in turn it must be a KVM related latency. (If there was any host side scheduler wakeup or other type of latency we'd see it in the trace.) The most useful trace would be a specific set of trace_printk() calls (available on the latest tracing tree), coupled with a hyper_trace_printk() which injects a trace entry from the guest side into the host kernel trace buffer. (== that would mean a hypercall that does a trace_printk().) Ingo