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
