[pulseaudio-discuss] Low-latency CPU consumption
tanuk at iki.fi
Fri Apr 5 10:14:01 PDT 2013
On Fri, 2013-04-05 at 11:10 +0200, David Henningsson wrote:
> 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.
I think there usually isn't any need to use memory barriers at all where
we use flists. For example, hashmaps use a global flist, but the
hashmaps themselves aren't accessed from multiple threads, so they could
use per-hashmap flists, and then we could have an flist implementation
that doesn't use any atomic variables.
I don't know what causes the biggest flist load, though, it may very
well be that it's the mempool, in which case a global flist is
More information about the pulseaudio-discuss