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