Posted Nov 12, 2009 17:42 UTC (Thu) by johnflux (subscriber, #58833)
Parent article: A futex overview and update
I don't know anything about Futexs etc, but given that the last few LWN articles have been along the lines of "The one big locking table was replaced with a per CPU table to increase scalability", do we expect to have an article in a year's time that the Futex hash table is now one-per-cpu ?
Posted Nov 12, 2009 21:30 UTC (Thu) by dvhart (guest, #19636)
[Link]
There has been more discussion along the lines of per-numa-node and per-
process tables to reduce false-sharing on the futex hash table, but the
effect is similar. One thing I feel is lacking a use-case that exemplifies
the contention on the hash-table and any cache-ping-pong it may cause on
multi-socket and/or multi-node systems. I'm working on a futex test suite
now and I hope some of the perf and stress tests will help here.
A futex overview and update
Posted Nov 16, 2009 0:48 UTC (Mon) by dlang (✭ supporter ✭, #313)
[Link]
one real-world example of lock ping-pong with futexes that I ran into recently was rsyslog (whould be reduced in recent versions)
it has threads that receive messages and add them to a (lock protected) queue, while other threads retrieve messages from the queue to output them.
with a simple UDP input and file output a high enough input rate could push it into lock contention, at which point throughput plummets. I can't say for sure that this is SMP cach line bouncing, but there's a good chance of this being the case.