Il 27/08/2013 16:44, Brian Rak ha scritto:
>> Il 26/08/2013 21:15, Brian Rak ha scritto:
>>> Samples: 62M of event 'cycles', Event count (approx.): 642019289177
>>> 64.69% [kernel] [k] _raw_spin_lock
>>> 2.59% qemu-system-x86_64 [.] 0x00000000001e688d
>>> 1.90% [kernel] [k] native_write_msr_safe
>>> 0.84% [kvm] [k] vcpu_enter_guest
>>> 0.80% [kernel] [k] __schedule
>>> 0.77% [kvm_intel] [k] vmx_vcpu_run
>>> 0.68% [kernel] [k] effective_load
>>> 0.65% [kernel] [k] update_cfs_shares
>>> 0.62% [kernel] [k] _raw_spin_lock_irq
>>> 0.61% [kernel] [k] native_read_msr_safe
>>> 0.56% [kernel] [k] enqueue_entity
>> Can you capture the call graphs, too (perf record -g)?
>
> Sure. I'm not entire certain how to use perf effectively. I've used
> `perf record`, then manually expanded the call stacks in `perf report`.
> If this isn't what you wanted, please let me know.
>
> https://gist.github.com/devicenull/7961f23e6756b647a86a/raw/a04718db2c26b31e50fb7f521d47d911610383d8/gistfile1.txt
>
This is actually quite useful!
- 41.41% qemu-system-x86 [kernel.kallsyms]
0xffffffff815ef6d5 k [k] _raw_spin_lock
- _raw_spin_lock
- 48.06% futex_wait_setup
futex_wait
do_futex
SyS_futex
system_call_fastpath
- __lll_lock_wait
99.32% 0x10100000002
- 44.71% futex_wake
do_futex
SyS_futex
system_call_fastpath
- __lll_unlock_wake
99.33% 0x10100000002
This could be multiple VCPUs competing on QEMU's "big lock" because the pmtimer
is being read by different VCPUs at the same time. This can be fixed, and
probably will in 1.7 or 1.8.
Thanks,
Paolo
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
