[pulseaudio-discuss] Low-latency CPU consumption

[Tanu Kaskinen]

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
appropriate.

-- 
Tanu