On Tue, Feb 5, 2013 at 1:26 AM, Marcelo Tosatti <mtosatti@xxxxxxxxxx> wrote: > - 'Steal time' is the amount of time taken while vcpu is able to run > but not runnable. Maybe 'vmexit latency' is a better name. You are right, 'vmexit latency' is a better name. > - Perhaps it would be good to subtract the time the thread was > involuntarily scheduled out due 'timeslice' expiration. Otherwise, > running a CPU intensive task returns false positives (that is, long > delays to due to reschedule due to 'timeslice' exhausted by guest CPU > activity, not due to KVM or QEMU issues such as voluntarily schedule in > pthread_mutex_lock). > > Alternatively you can raise the priority of the vcpu threads (to get rid > of the false positives). I think this depends on the use-case. If the aim is to find out why the guest has poor response times then timeslice expiration is interesting. If the aim is to optimize QEMU or kvm.ko then timeslice expiration is a nuisance :). Your idea to raise the vcpu thread priority sounds good to me. > - Idea: Would be handy to extract trace events in the offending > 'latency above threshold' vmexit/vmentry region. > Say that you enable other trace events (unrelated to kvm) which can > help identify the culprit. Instead of scanning the file manually > searching for "100466.1062486786" save one vmexit/vmentry cycle, > along with other trace events in that period, in a separate file. Good idea. Stefan -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
