Re: [Bug #12465] KVM guests stalling on 2.6.28 (bisected)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux