Ingo Molnar wrote:
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.)
But if there's a missing wakeup (which is the likeliest candidate for
the bug) then we would have seen high latencies, no?
Can you explain what the patch in question (14800984706) does? Maybe
that will give us a clue.
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().)
Yes, that would provide all the information. Not sure if I would be up
to decoding it, though.
--
error compiling committee.c: too many arguments to function
--
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
