On Mon, Jul 21, 2014 at 09:34:57PM -0400, Steven Rostedt wrote: > I just want to point out that I was having a very nice conversation > with Robert Haas (Cc'd) in Napa Valley at Linux Collaboration about > this very topic. Robert is a PostgeSQL developer who told me that they > implement their spin locks completely in userspace (no futex, just raw > spinning on shared memory). This is because the sleep on contention of a > futex has shown to be very expensive in their benchmarks. His work is > not a micro benchmark but for a very popular database where locking is > crucial. Userspace spinlocks are a clusterfuck. Its impossible to solve the priority inversion trainwrecks they cause _ever_. We've had -- as I think Mike already pointed out -- tons of 'fun' with psql exactly because its doing this :-( > I was telling Robert that if futexes get optimistic spinning, he should > reconsider their use of userspace spinlocks in favor of this, because > I'm pretty sure that they will see a great improvement. > > Now Robert will be the best one to answer if the system call is indeed > more expensive than doing full spins in userspace. If the spin is done > in the kernel and they still get better performance by just spinning > blindly in userspace even if the owner is asleep, I think we will have > our answer. No, the best way is to measure the exact syscall cost. If he still gets better performance we need to analyze why, there might be something else hiding there. > Note, I believe they only care about shared threads, and this > optimistic spinning does not need to be something done between > processes. There's no reason not to provide it for shared futexes, in fact I suspect not doing it for shared futexes is going to make the code uglier. Anyway, there is one big fail in the entire futex stack that we 'need' to sort some day and that is NUMA. Some people (again database people) explicitly do not use futexes and instead use sysvsem because of this. The problem with numa futexes is that because they're vaddr based there is no (persistent) node information. You always end up having to fall back to looking in all nodes before you can guarantee there is no matching futex. One way to achieve it is by extending the futex value to include a node number, but that's obviously a complete ABI break. Then again, it should be pretty straight fwd, since the node number doesn't need to be part of the actual atomic update part, just part of the userspace storage. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
