* Avi Kivity <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
