[pulseaudio-discuss] Low-latency CPU consumption

Tanu Kaskinen 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 mailing list