Yesterday afternoon I tried to look a bit on where PulseAudio spends its
time. In a low-latency scenario PulseAudio seems to be a bit CPU intensive.
The tests were done with perf analyzing PulseAudio git master + a 3.2
kernel, and an AMD CPU that's ~3 years old or so. After starting
PulseAudio I ran a 10 ms playback latency test during 30 seconds.
I'm still learning to master perf, but here are some initial results:
1) The top four functions (and more than half of the top 20) are all in
the kernel, and a result from the ppoll call. It seems like we do about
10 ppolls for every packet: three in the I/O thread and seven in the
main thread. The majority of the main thread ppolls are due to the
iochannel, i e talking to the client.
It looks like the iochannel is a bit inoptimal in its construction,
requiring more ppolls than should be necessary. But I have to analyze
this deeper. (I did a simple attempt to optimise it yesterday but it
didn't work.)
2) Second is all the atomic operations we do, in handling our flists.
There seem to be quite a penalty for doing memory fence operations, and
there are plenty of those for just getting/putting something into an
flist. Here it might also be possible to optimise things, maybe we can
use a more efficient memory recycle mechanism for the most common
workload or so.
3) Third is asking the kernel for the current hardware pointer. I have
not looked into this deeper yet, but it's possible that we ask several
times for the current hardware position where we should ask only once.
--
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic
+ 2.55% lt-pulseaudio [kernel.kallsyms] [k] do_poll.isra.4
◆
+ 2.34% lt-pulseaudio [kernel.kallsyms] [k] fget_light
▒
+ 2.14% lt-pulseaudio [kernel.kallsyms] [k]
_raw_spin_unlock_irqrestore
▒
+ 2.07% lt-pulseaudio [kernel.kallsyms] [k] _raw_spin_lock_irqsave
▒
+ 1.85% lt-pulseaudio [snd_hda_intel] [k] 0xc24
▒
+ 1.55% lt-pulseaudio [kernel.kallsyms] [k] find_busiest_group
▒
+ 1.53% lt-pulseaudio [kernel.kallsyms] [k] tg_load_down
▒
+ 1.43% lt-pulseaudio libpulsecommon-3.0.so [.] stack_pop
▒
+ 1.37% lt-pulseaudio libpulsecommon-3.0.so [.] pa_memblock_unref
▒
+ 1.11% lt-pulseaudio libalsa-util.so [.] thread_func
▒
+ 1.06% lt-pulseaudio libpulsecommon-3.0.so [.] stack_push
▒
+ 1.05% lt-pulseaudio [kernel.kallsyms] [k] unix_poll
▒
+ 0.93% lt-pulseaudio [vdso] [.] 0x7fff2c1768c5
▒
+ 0.89% lt-pulseaudio ld-2.15.so [.] check_match.11236
▒
+ 0.84% lt-pulseaudio libpulse.so.0.15.3 [.] pa_mainloop_dispatch
▒
+ 0.80% lt-pulseaudio [kernel.kallsyms] [k] __ticket_spin_lock
▒
+ 0.79% lt-pulseaudio [kernel.kallsyms] [k] ret_from_sys_call
▒
+ 0.72% lt-pulseaudio [kernel.kallsyms] [k] do_sys_poll
▒
+ 0.68% lt-pulseaudio [kernel.kallsyms] [k] fput
▒
+ 0.68% lt-pulseaudio [kernel.kallsyms] [k] system_call
▒
+ 0.68% lt-pulseaudio [kernel.kallsyms] [k] update_cfs_load
▒
+ 0.66% lt-pulseaudio [kernel.kallsyms] [k] __schedule
▒
+ 0.66% lt-pulseaudio libpulsecommon-3.0.so [.] do_something
▒
+ 0.65% lt-pulseaudio [kernel.kallsyms] [k] fsnotify
▒
+ 0.62% lt-pulseaudio libpulse.so.0.15.3 [.] pa_mainloop_prepare
▒
+ 0.62% lt-pulseaudio [kernel.kallsyms] [k] sysret_check
▒
+ 0.60% lt-pulseaudio [kernel.kallsyms] [k] __pollwait
▒
+ 0.58% lt-pulseaudio [kernel.kallsyms] [k] copy_user_generic_string
▒
+ 0.57% lt-pulseaudio libpulsecommon-3.0.so [.] pa_flist_pop
▒
+ 0.55% lt-pulseaudio [kernel.kallsyms] [k] eventfd_poll
▒
+ 0.53% lt-pulseaudio [kernel.kallsyms] [k] native_write_msr_safe
▒
+ 0.52% lt-pulseaudio [kernel.kallsyms] [k] find_next_bit
▒
+ 0.51% lt-pulseaudio libpulsecore-3.0.so [.] pa_rtpoll_run
▒
_______________________________________________
pulseaudio-discuss mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
